Am Fr., 20. Nov. 2020 um 13:23 Uhr schrieb Thiede, Christoph
<Christoph.Thiede at student.hpi.uni-potsdam.de>:
>
> > 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?
>
>
> Hm, quite long names. :-) How about #hasUniqueDescription? #isDescription[Globally]Unique? Something like that? :-)
>

I was also tinkering with "unique", but the problem is that the
descriptions are not unique. Different definitions of the same method
have equal descriptions, that's the point. Description itself is a
rather abstract term here. It is more like the key for an index (and
it is used as such in dictionaries).

Thinking out loud to inspire others to find a better name: As of now,
the objects defined by these MCDefinitions exist at most once (= are
unique) in an Environment at any point in time. To say the same for
MCOrganizationDefinition and MCScriptDefinition, as of now, you would
in addition have to give the package name. For those kinds of
definitions that you want to skip here, you say the definitions cannot
be distinguished by their description if you combine the patches of
multiple packages. Well, actually that's not entirely true:
MCScriptDefinition has the packageName in its description, so you can
manage scripts of multiple packages in the same patch and they are
immune to your consolidation procedure -- but unlike classes, traits,
and methods, you cannot say that this script is still the same if you
move it to another package. For the identity of classes, traits, and
methods, the package is irrelevant (unlike in other languages) and
therefore the removals and additions across packages can be
consolidated. The package is just a filter superimposed on these
objects, whereas each script is associated with a package directly.
MCOrganizationDefinition is not officially associated with a package,
but its instances usually contain only the categories of just a single
package. And conversely, packages are delimited/defined/identified by
categories.

canMoveBetweenPackages?

Later you might change some of the premises, such as: either add the
packageName to MCOrganizationDefinition's description, or consolidate
MCOrganizationDefinitions if you do a cross-package load so it does
contain categories from multiple packages. Then you could also
consolidate the operations like for methods (although with a different
algorithm in the second approach).

Or you stick with your isOrganizationMember, but promise to refactor
very soon, so it does not stick around. ;-)