debugging with slot is not really cool since we get FMSlot everywhere instead of the reference to the exact object.
Then I was wondering what is the exact gain: we do not duplicate the management of what exactly? Because we are trading coding the management of the relation by space (the slot objects) and speed we send value all the times everywhere now.
May be for FAME it is better to generate Slot instead of methods in the class. But so far I do not know exactly what is the gain. because I still have to define add/remove.... in the interface of the class that has a slot.
It seems to me that this is meta programming for the poor. Ideally Smalltalk would have a nice meta object protocol and we would define a Slot metaobject and say it in the class and we would get the management at runtime or may be at compile time.
Now it looks to me like an overhead without any real gain.
Stef
Now it looks to me like an overhead without any real gain.
As far as I know from the few hours I helped with the port, the slots automatically update the opposite relationships. So if you add an attribute to a class, the attribute will automatically point back to the owning class. The same same happens if you set the owning class of an attribute to a different class all the relationships are automatically updated.
The few times I used the "old" Moose I found it quite annoying and error prone that I had to manage all these opposite relationships manually. I think this is a big advantage, if I observed all this correctly. I might well be wrong ...
Lukas
Now it looks to me like an overhead without any real gain.
As far as I know from the few hours I helped with the port, the slots automatically update the opposite relationships. So if you add an attribute to a class, the attribute will automatically point back to the owning class. The same same happens if you set the owning class of an attribute to a different class all the relationships are automatically updated.
The few times I used the "old" Moose I found it quite annoying and error prone that I had to manage all these opposite relationships manually.
When you created a new metamodel: probably. even if aClass remove: aMethod and aMethod setBelongTo: nil (not even necessary) is not that complex.
I think this is a big advantage, if I observed all this correctly. I might well be wrong ...
You are right but in Famix how many times do you code the FAMIX metamodel: once every three to five or eight years. And what is the cost: getting a slot and sending values all the time. Nothing is free.
My biggest concern is that we are using a technology from people that do not care at all of moose. So I'm concerned that I will have to understand all the things that Moose use as infrastructure, because I will maintain and want build on top of moose.
So Slot are probably cool to generate new metamodel. But we could generate directly the method doing the manipulation without having a slot object in our way.
Stef
-
Lukas Renggli -
Stéphane Ducasse