Add a #destroy message to (conditionally) remove project SymbolDictionaries from the system

[dalehenrich]

@tukanos has noted that the SymbolDictionary is not removed when the project is unloaded in this issue ...

It needs to be an option, because Rowan as no knowledge about whether or not the symbol dictionary is being used by other projects or not, however, if the user explicitly declares that they want the symbol dictionary removed when the project is unloaded, that it can be done...

[tukanos]

Hello @dalehenrich ,

...if the user explicitly declares that they want the symbol dictionary removed when the project is unloaded, that it can be done.

Yes, that is great idea too. Wouldn't be possible to have also an option #ifEmpty when removing the dictionary? Can the dictionary be used by other projects if it is completely empty?

[dalehenrich]

Wouldn't be possible to have also an option #ifEmpty when removing the dictionary? Can the dictionary be used by other projects if it is completely empty?

Can the dictionary be used by other projects if it is completely empty?
Well that is an application specific question ...

There are potential problems with unloading a project with or without SymbolDictioinaries ... a user could have subclassed one of the classes in the project you are unloading or the class could be referenced in a method that remains behind. The method could be owned by a user for which the current user does not have read permission ... and many more.

As I think about it it really only make sense to have the user take responsibility for cleaning up the system in the aftermath of a project unload.

I will close this issue and mark it wontfix, but feel free to re-open it if you want to continue the discussion.

[tukanos]

Wouldn't be possible to have also an option #ifEmpty when removing the dictionary? Can the dictionary be used by other projects if it is completely empty?

Can the dictionary be used by other projects if it is completely empty?
Well that is an application specific question ...

There are potential problems with unloading a project with or without SymbolDictioinaries ... a user could have subclassed one of the classes in the project you are unloading or the class could be referenced in a method that remains behind. The method could be owned by a user for which the current user does not have read permission ... and many more.

As I think about it it really only make sense to have the user take responsibility for cleaning up the system in the aftermath of a project unload.

I will close this issue and mark it wontfix, but feel free to re-open it if you want to continue the discussion.

Hello, @dalehenrich ,

I do not have permission to reopen the issue. While I understand why you are hesitant to unload it for the user automatically, I still think there should at least a warning for the user that is unloading a project. There are so many things to think of. This introduces a new error/exception surface.

If the user is a SystemUser than you could check the dependencies than perhaps ask the user if they want to remove the dictionary?

[dalehenrich]

@tukanos,

reopening ... Okay, I understand your concerns, and instead of an option, I think this probably calls for a destroy command. If you are intending to destroy a project then the checks and warnings would make much more sense... in fact I'd be inclined that the symbol dictionary check would take place BEFORE the project and symbol dictionaries are removed to see if there any non-project classes present in the symbol dictionaries involved in the GUI, the list of things that will be removed from the system could be presented to the user prior as part of an "are you sure dialog".

I'll change the title of this issue and and the related JfP issue ...