JADE Environment Development Ideas

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;
   vars
   begin
   return null;
   end;
   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.