sbragagnolo
commented
2 years ago This extension of the slot work delegates the management of instance values to the proper slots, instead of using 'isToOne' or 'isToMany' This allows us now to have different kind of slot implementations. The access now also provides a virtual slot . When ever realInverseSlot: is invoked, instead of returning a slot or an error finding a slot it gives the proper slot or a virtual slot.
The virtual slot allows the user to link different objects that may not have the slot yet. This new feature give us some benefits such as:
1- The error for back-adding an entity is readable (being a message not understood) 2- The virtual slot can be leveraged for:
- linking stub objects to specific references
- allow the flux of a debugging session to keep on going, regardless the fact that class is not yet having a slot.
- Being used as a analyzable object instead of a generic exception for the sake of coding refactoring proposal during debugging sessions.
Discussion:
The slots originally store the reverse slot object in a dictionary related with the type. Slots objects are created on command, and store circumstantial information such as the index in the instance variables array. This information is meant to get out-dated when what-ever structural changes happen (such as modifying trait composition order, adding an instance variable in a class or superclass, etc).
For avoiding this problem of out-dating we changed the implementation to store in the cache a message send object.
This could eventually penalize the execution time performance. Never the less the other oportunity is to flush a cache on all the instances of a many classes. This could be quite complex in the case of a complex model with many instances (a common scenario in the context of moose)