-
-
Notifications
You must be signed in to change notification settings - Fork 348
03 PhIP Cleanup ProtocolOrganizer ClassOrganization
- For Pharo10.
- Reason: Simplification and reduction of memory usage.
Every class and metaclass has a ClassOrganizer which in turn has a ProtocolOrganizer. This means we have 2 instances per class and metaclass.
The main responsibility is to provide an API for and implement method categorization/protocols.
In addition, the ClassOrganizer keeps the commentSourcePointer. This leads to meta-classes having a nil commentSourcePointer via their ClassOrganizer. Else the ClassOrganizer provides the API for protocols and categories but is actually forwarding all that to ProtocolOrganizer
We should clean this up step-by-step to, for one, save memory and for simplicity. I propose to do 3 steps:
- Step 1: move commentSourcePointer to Class.
- Step 2: Merge ClassOrganization and ProtocolOrganizer
- Step 3: remove the Organizer and let ClassDescription handle it.
commentSourcePointer should be in the Class. This way we do not have to have a nil ivar for every metaclass.
This change is quite easy but will lead to some deprecated method in the level of the ClassOrganizer.
I think the only reason why this was not done was that nobody dared to add an ivar to Class, which is hard to do without a boostrap.
- every ClassOrganization object has one ProtocolOrganizer
- most of the API forwards from ClassOrganization to ProtocolOrganizer -- it is clear that we can merge the two -- there are "old" and "new" APIs: category vs. Protocol
Protocol just is a name and a collection of selectors, ProtocolOrganizer just has a collection of those. The only thing that is managed explicitly is the #all category.
Why not let the class manage the protocols? Do we need an "organizer" at all? We can just have one instance variable "protocols" which is "organized" by ClassDescription.
After these simplifications, we should re-visit the Protocol API.