Am Mo., 16. Nov. 2020 um 18:22 Uhr schrieb Thiede, Christoph
<Christoph.Thiede at student.hpi.uni-potsdam.de>:
>
> However, since you're commenting this, I'm asking myself two questions:
>
> Is it a valid operation to remove an entire organization definition under any circumstances?

taH pagh taHbe (To be, or not to be)... [1]
There is always an organization as long as there is a package.
Removing the package organization is only valid when you unload
(remove) the whole package. According to
MCOrganizationDefinition>>#unload it would only remove empty
categories anyway.

[1] https://en.wikipedia.org/wiki/The_Klingon_Hamlet

> Couldn't we instead modify the #definition implementation of MCOrganizationDefinition and insert the containing system category name at this place? Semantically, this would look better for me, but unfortunately, MCOrganizationDefinition does not have a relevant instance variable ...
>

Did you mean #description instead? In absence of a packageName
variable, it would have to find the common prefix of the elements in
its categories variable. Though for cross-package loads, it must be
made sure that it still behaves correctly
(GoferLoad>>#updateCategories).

I suggest to check or resolve that later and keep the current
behavior, to not block your current contribution.

> > In domain terms, why is it significant here that the definitions are members of an organization? Why does this procedure not apply to organization changes or script changes, for example?
>
> Fair question. #description is only unique for a definition that is part of an organization. Given a set of two MCVersions one of which would add and the second one would delete an MCOrganizationDefinition for separate packages, by the current implementation these organization definitions would be revisions of each other and thus would be wiped up in #forgetSuperfluousMethodRemovals.
>

Instead for now, is there a more meaningful selector than
isOrganizationMember given that this property just corresponds to
another one that you are really looking for?
canDistinguish[SomethingLikeInstancesOrTheOppositeOfRevisionsOfAnother],
canDistinguishRevisionsFromOtherObjects,
canDistinguishRevisionsAcrossPackages?

Or override isRevisionOf:, but then it would be inconsistent with
behavior that relies on description directly for the time being (e. g.
hash --> Dictionary overwriting).