JADE Environment Development Ideas

What's new in the upcoming JADE release?


The JADE 2022 release meets tomorrow’s business demands.

Start your update to JADE's latest release

General Interface improvements and fixes

This is aimed at improving the developer experience and time spent for anyone using Interfaces in Jade.

  1. Review method options that make sense for interface methods.

    Every single time I've declared a setter method on an interface and implemented it, I've had to go to the implementer and add the method option "updating". This is a huge pain when you have many setter methods, and many implementers.

    Trying to add updating to the method options in the interface results in "6019 Invalid option". As far as I'm concerned, what is generated for an interface method is just copied from the interface definition/method signature, and there isn't a reason I can think of for why it can't contain the updating option.

    Bizarrely, using condition works, but generates the method wrong. The interface method for an example

    IUser::has2fa() : Boolean condition;
    Compiles fine! But when implementing it on User, has2fa() turns into

    stub_Has2fa() : Boolean:Boolean condition;
    return null;
    With a resulting 7054 because using condition on the interface method declaration seems to have added an additional boolean return signature on the generated method. It has also generated the method with an invalid vars section.

    Clever people may suggest utilizing the elusive feature in https://secure.jadeworld.com/JADETech/JADE2022/OnlineDocumentation/content/resources/userguide/ch14interfaces/compiling_an_interface_method.htm
    Where it explains you can put your caret at the start of the brackets of the method signature and press Ctrl+1/2/3 to correct it. This works for the most part - it doesn't account for any part of the existing signature on the right side though. It'd be nice if it accounted for that and deleted it or commented it out if the signature had comments in it, so it could be recompiled straight away.

    To sum that up - I expect to be able to use the method options updating, lockReciever in interface method definitions. Use of condition should generate the stub without the vars section. There may be other method options that are relevant. Due to existing pains in using the obvious ones I haven't tried any others so I wouldn't know, but welcome anyone to provide use cases for others.

    Touching up the method signature fixing feature would be nice too.

  2. When removing an interface from a class, remove any generated stub methods automatically.

    1. Maybe with the exception of interface methods that were configured to map to existing methods. Leaving pre-existing methods may be desirable though, so potentially add a preference for it.

    This would save a lot of clicks for removing code.
    There's room for discussion for this one too, as automatically removing the method when it has references could cause a cascading headache. It could be put behind an option when removing the interface, or it could be prevented outright until the dev cleans up any references.

  • Kara Heffernan
  • Jan 2 2024
  • Needs review
  • Attach files