Hi,
I totally agree that the "base programmer" needs to be supported, but on the other hand we should offer the tools to extend Moose. It is just that I do not understand exactly what the advantages/ disadvantages are, and I propose to start a discussion on that.
I do not understand exactly the solution, but here is what I understood as the reasons for wide classes: 1. extend the state of a class from another package 2. save memory by only allocating a instance variable slot when it is used 3. (speed?)
1. In VW we can extend the methods and that allowed us to have a nice extensible architecture. In the same way, we should be able to extend the state as well, for example for caching results performed by a method extension.
That is why currently, we have __state__ in each entity that has dictionaries for storing such results, and we wrap the calls to __state__ in setters and getters. For example, in DynaMoose we have:
FAMIXClass>>instances ^self __state__ attributeGet: #instances initializer: [ OrderedCollection new ] FAMIXClass>>instances: aCollection ^self __state__ attributeSet: #instances value: aCollection
The symbol is only used here. All tools work nicely with that (actually, in VW looking for senders of a method will also get you the usages of the symbol). This mechanism is crucial for extending the meta-model.
The wide classes solution would pose the same overhead on the programmer.
2. The second reason for the wide classes is to reduce the memory footprint, because you will only get a slot if you use it.
The current solution will create a dictionary for all instance variables extensions and an entry for each of them. I would be curious to see what the difference is.
3. Speed. I am definitely not sure about this point, but wide classes should be faster than looking into a dictionary. But, I do not believe this has a real impact over the overall performance, in particular given that the dictionary are rather small.
Of course, you can just bash anything I wrote here :)
Doru
-- www.tudorgirba.com www.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
Please do not use wide classes as a term to refer to class that could have key based attributes. Wide classes is first a bad name (read the paper you will see that this is more shapeChanging instances).
There is a difference between wanted to have shapechanginginstance and key (like in dictionary) based attributes.
When reading the examples of adrian and my own experience trying to fix JAM (the XML fucking based Java importer of Michael locher, and Squeak Morph extension mechanism) I would like to have key-based attributes (but not wideclasses).
On 22 nov. 07, at 23:09, Tudor Girba wrote:
Hi,
I totally agree that the "base programmer" needs to be supported, but on the other hand we should offer the tools to extend Moose. It is just that I do not understand exactly what the advantages/ disadvantages are, and I propose to start a discussion on that.
I do not understand exactly the solution, but here is what I understood as the reasons for wide classes:
- extend the state of a class from another package
- save memory by only allocating a instance variable slot when it is
used 3. (speed?)
- In VW we can extend the methods and that allowed us to have a nice
extensible architecture. In the same way, we should be able to extend the state as well, for example for caching results performed by a method extension.
That is why currently, we have __state__ in each entity that has dictionaries for storing such results, and we wrap the calls to __state__ in setters and getters. For example, in DynaMoose we have:
FAMIXClass>>instances ^self __state__ attributeGet: #instances initializer: [ OrderedCollection new ] FAMIXClass>>instances: aCollection ^self __state__ attributeSet: #instances value: aCollection
The symbol is only used here. All tools work nicely with that (actually, in VW looking for senders of a method will also get you the usages of the symbol). This mechanism is crucial for extending the meta-model.
Sounds a good solution to me. Having VariableHashtableSubclass would just push this kind of code in the bytecode and the programmer could write
FAMIXClass>>instances ^ instances
this would be like in Python
I do not think that we should change dynamically the class of an object to introduce wideclasses. (again please read the paper).
The wide classes solution would pose the same overhead on the programmer.
- The second reason for the wide classes is to reduce the memory
footprint, because you will only get a slot if you use it.
The current solution will create a dictionary for all instance variables extensions and an entry for each of them. I would be curious to see what the difference is.
- Speed. I am definitely not sure about this point, but wide classes
should be faster than looking into a dictionary. But, I do not believe this has a real impact over the overall performance, in particular given that the dictionary are rather small.
Of course, you can just bash anything I wrote here :)
Nooooo :) We are not that mean.
Stef
Doru
-- www.tudorgirba.com www.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
You are right, I was referring to key-based attribute, ie dynamic inst vars, not Serrano style wide classes.
AA
On 23 Nov 2007, at 8:49 , Stéphane Ducasse wrote:
Please do not use wide classes as a term to refer to class that could have key based attributes. Wide classes is first a bad name (read the paper you will see that this is more shapeChanging instances).
There is a difference between wanted to have shapechanginginstance and key (like in dictionary) based attributes.
When reading the examples of adrian and my own experience trying to fix JAM (the XML fucking based Java importer of Michael locher, and Squeak Morph extension mechanism) I would like to have key-based attributes (but not wideclasses).
On 22 nov. 07, at 23:09, Tudor Girba wrote:
Hi,
I totally agree that the "base programmer" needs to be supported, but on the other hand we should offer the tools to extend Moose. It is just that I do not understand exactly what the advantages/ disadvantages are, and I propose to start a discussion on that.
I do not understand exactly the solution, but here is what I understood as the reasons for wide classes:
- extend the state of a class from another package
- save memory by only allocating a instance variable slot when it is
used 3. (speed?)
- In VW we can extend the methods and that allowed us to have a nice
extensible architecture. In the same way, we should be able to extend the state as well, for example for caching results performed by a method extension.
That is why currently, we have __state__ in each entity that has dictionaries for storing such results, and we wrap the calls to __state__ in setters and getters. For example, in DynaMoose we have:
FAMIXClass>>instances ^self __state__ attributeGet: #instances initializer: [ OrderedCollection new ] FAMIXClass>>instances: aCollection ^self __state__ attributeSet: #instances value: aCollection
The symbol is only used here. All tools work nicely with that (actually, in VW looking for senders of a method will also get you the usages of the symbol). This mechanism is crucial for extending the meta-model.
Sounds a good solution to me. Having VariableHashtableSubclass would just push this kind of code in the bytecode and the programmer could write
FAMIXClass>>instances ^ instances
this would be like in Python
I do not think that we should change dynamically the class of an object to introduce wideclasses. (again please read the paper).
The wide classes solution would pose the same overhead on the programmer.
- The second reason for the wide classes is to reduce the memory
footprint, because you will only get a slot if you use it.
The current solution will create a dictionary for all instance variables extensions and an entry for each of them. I would be curious to see what the difference is.
- Speed. I am definitely not sure about this point, but wide classes
should be faster than looking into a dictionary. But, I do not believe this has a real impact over the overall performance, in particular given that the dictionary are rather small.
Of course, you can just bash anything I wrote here :)
Nooooo :) We are not that mean.
Stef
Doru
-- www.tudorgirba.com www.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Stéphane Ducasse -
Tudor Girba