Re: [Pharo-project] instVarNames vs instVarNamed:
...makes me envy the simplicity of SELF! Fernando On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 September 2012 08:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote:
okay, i found what is wrong with first post (didn't read carefully).
The instVarNames is a class-side protocol i.e. part of a class behavior, while instVarNamed: is an instance-side protocol i.e. "hackishly access to instance variable with given name"
Yes this is exactly my point. I think that there is a protocol missing for class to be consistent.
err, what is missing? class is an object, and using #instVarNamed: on them is perfectly fine.
So, this is ok: Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
And this is ok too:
Nautilus instVarNamed: 'groups' worked
because Nautilus is an instance of its metaclass.
But this is wrong, since 'Nautilus class' is an instance of Metaclass, and metaclass doesn't have 'groups' variable.
Nautilus class instVarNamed: 'groups' -> error
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I still don't see the problem.... everything is symmetrical, everything works... On 2012-09-24, at 11:18, Fernando Olivero <fernando.olivero@usi.ch> wrote:
...makes me envy the simplicity of SELF!
Fernando
On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 September 2012 08:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote:
okay, i found what is wrong with first post (didn't read carefully).
The instVarNames is a class-side protocol i.e. part of a class behavior, while instVarNamed: is an instance-side protocol i.e. "hackishly access to instance variable with given name"
Yes this is exactly my point. I think that there is a protocol missing for class to be consistent.
err, what is missing? class is an object, and using #instVarNamed: on them is perfectly fine.
So, this is ok: Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
And this is ok too:
Nautilus instVarNamed: 'groups' worked
because Nautilus is an instance of its metaclass.
But this is wrong, since 'Nautilus class' is an instance of Metaclass, and metaclass doesn't have 'groups' variable.
Nautilus class instVarNamed: 'groups' -> error
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Mon, Sep 24, 2012 at 12:14 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
I still don't see the problem....
everything is symmetrical, everything works...
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups') ok we get the instance variables Nautilus class instVarNamed: 'groups' -> error For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent. Cheers,
On 2012-09-24, at 11:18, Fernando Olivero <fernando.olivero@usi.ch> wrote:
...makes me envy the simplicity of SELF!
Fernando
On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 September 2012 08:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote:
okay, i found what is wrong with first post (didn't read carefully).
The instVarNames is a class-side protocol i.e. part of a class
behavior,
while instVarNamed: is an instance-side protocol i.e. "hackishly access to instance variable with given name"
Yes this is exactly my point. I think that there is a protocol missing for class to be consistent.
err, what is missing? class is an object, and using #instVarNamed: on them is perfectly fine.
So, this is ok: Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
And this is ok too:
Nautilus instVarNamed: 'groups' worked
because Nautilus is an instance of its metaclass.
But this is wrong, since 'Nautilus class' is an instance of Metaclass, and metaclass doesn't have 'groups' variable.
Nautilus class instVarNamed: 'groups' -> error
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
On 24 September 2012 17:57, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Mon, Sep 24, 2012 at 12:14 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I still don't see the problem....
everything is symmetrical, everything works...
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
because you sending a message to wrong recepient. Should be: Nautilus instVarNamed: 'groups'
Cheers,
On 2012-09-24, at 11:18, Fernando Olivero <fernando.olivero@usi.ch> wrote:
...makes me envy the simplicity of SELF!
Fernando
On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 September 2012 08:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote:
okay, i found what is wrong with first post (didn't read carefully).
The instVarNames is a class-side protocol i.e. part of a class behavior, while instVarNamed: is an instance-side protocol i.e. "hackishly access to instance variable with given name"
Yes this is exactly my point. I think that there is a protocol missing for class to be consistent.
err, what is missing? class is an object, and using #instVarNamed: on them is perfectly fine.
So, this is ok: Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
And this is ok too:
Nautilus instVarNamed: 'groups' worked
because Nautilus is an instance of its metaclass.
But this is wrong, since 'Nautilus class' is an instance of Metaclass, and metaclass doesn't have 'groups' variable.
Nautilus class instVarNamed: 'groups' -> error
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
not at all... the class holds all the structural information. The class holds the description of the instances... The very same goes for methods: - You ask the class for the available methods - You invoke them on instances in parallel - You ask the class for the available variables - You ask the instance for the values of the variables So again: All structural information should be on the class side, all actual values have to be extracted from a living instance. I guess by having first-class layouts this discussion would be simplified, since slots/variables become first class instances. Plus adhering to strict naming conventions you will avoid this confusion Slots: the description (meta-object) of a Variable Variable: living instances with actual values on the objects furthermore you can then use the slot to read the variable from an instance :) and the circle is closed :) best cami
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class. The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there. unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
What if we do it the other way? Add #variableNames to the instances :) Nautilus new variableNames = Nautilus instVarNames. And them Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass') Nautilus new instVarNamed: 'announcer' ? Of course, that will happen/work at metaclass level too. Maybe rename #instVarNames to #myInstancesVariableNames? Guille On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
On 2012-09-24, at 20:24, Guillermo Polito <guillermopolito@gmail.com> wrote:
What if we do it the other way? Add #variableNames to the instances :)
in my opinion wrong :/, then you can start to replicate the whole class-side interface on the instance side... that's a never-ending circle. besides, that's yet another method on Object? :D
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:28 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-09-24, at 20:24, Guillermo Polito <guillermopolito@gmail.com> wrote:
What if we do it the other way? Add #variableNames to the instances :)
in my opinion wrong :/, then you can start to replicate the whole class-side interface on the instance side... that's a never-ending circle.
I'm not strongly against nor in favor for any of those approaches.
besides, that's yet another method on Object? :D
The problem is not the amount of methods per se but the packaging of most of them -which btw is much better than some years ago-, and the tools showing lots of info in such annoying way.
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:24 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
Maybe rename #instVarNames to #myInstancesVariableNames?
+1. I think something around this would clarify this scenario. Because for me Class is a normal object...
Guille
On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
-- Mariano http://marianopeck.wordpress.com
No just make instVarNamed: work on Class/Metaclass On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote:
What if we do it the other way? Add #variableNames to the instances :)
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com> wrote: On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
On Mon, Sep 24, 2012 at 10:57 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
No just make instVarNamed: work on Class/Metaclass
but then you won't be able to reach the normal instance variables of a class (the metaclass): Nautilus class instVarNamed: 'format' -> 164 I won't be able to do that if we override #instVarNamed: That's why I think I prefer the rename to #myInstancesVariableNames
On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote:
What if we do it the other way? Add #variableNames to the instances :)
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com> wrote: On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
-- Mariano http://marianopeck.wordpress.com
On 24 September 2012 22:57, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
No just make instVarNamed: work on Class/Metaclass
but it works! Wake up: Object instVarNamed: 'superclass' ==> ProtoObject Object class instVarNamed: 'superclass' =>>> ProtoObject class while #instVarNames is an accessor method, since you have: ProtoObject subclass: #Object instanceVariableNames: '' <<< ---- from here classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects' so, Object instVarNames ==> #() Point instVarNames #('x' 'y') And if you want to know, what instance variables an Object (as an object) has, you can always do: Object class allInstVarNames #('superclass' 'methodDict' 'format' 'layout' 'instanceVariables' 'organization' 'subclasses' 'name' 'classPool' 'sharedPools' 'environment' 'category' 'traitComposition' 'localSelectors') And then , access the values: Object instVarNamed: 'category' ==> #'Kernel-Objects' And then what Mariano proposing with renaming an accessor to 'myInstVarNames' sounds like an absurd, then we should probably think about renaming all accessors in all classes like that, i.e. instead (1@2) x we should write (1@2) myX or #getX and so on..
On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote:
What if we do it the other way? Add #variableNames to the instances :)
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com> wrote: On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
-- Best regards, Igor Stasenko.
I don't see the problem either. I think the best way to see it is to send instVarNames to any object that isn't a Behavior. That way one get a MNU. So instVarNames is a behavior defined only for objects describing behavior. And instVarNamed: is a behavior of any object for accesing its instance variables. As classes are first class objects they also define this behavior. If any problem i think it should be on finding better names so confusion is avoided. Cheers, Guido. 2012/9/24 Igor Stasenko <siguctua@gmail.com>
On 24 September 2012 22:57, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
No just make instVarNamed: work on Class/Metaclass
but it works! Wake up:
Object instVarNamed: 'superclass' ==> ProtoObject Object class instVarNamed: 'superclass' =>>> ProtoObject class
while #instVarNames is an accessor method, since you have:
ProtoObject subclass: #Object instanceVariableNames: '' <<< ---- from here classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects'
so, Object instVarNames ==> #()
Point instVarNames #('x' 'y')
And if you want to know, what instance variables an Object (as an object) has, you can always do:
Object class allInstVarNames
#('superclass' 'methodDict' 'format' 'layout' 'instanceVariables' 'organization' 'subclasses' 'name' 'classPool' 'sharedPools' 'environment' 'category' 'traitComposition' 'localSelectors')
And then , access the values:
Object instVarNamed: 'category' ==> #'Kernel-Objects'
And then what Mariano proposing with renaming an accessor to 'myInstVarNames' sounds like an absurd, then we should probably think about renaming all accessors in all classes like that, i.e. instead
(1@2) x
we should write
(1@2) myX
or #getX and so on..
On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote:
What if we do it the other way? Add #variableNames to the instances :)
Nautilus new variableNames = Nautilus instVarNames.
And them
Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins'
'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass')
Nautilus new instVarNamed: 'announcer'
?
Of course, that will happen/work at metaclass level too.
Maybe rename #instVarNames to #myInstancesVariableNames?
Guille
On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni@gmail.com>
wrote:
On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
-- Best regards, Igor Stasenko.
On Sep 24, 2012, at 8:18 PM, Camillo Bruni wrote:
On 2012-09-24, at 20:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote:
Nautilus class instVarNames -> #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
Nautilus class instVarNamed: 'groups' -> error
For me that is wrong. I should not get an error, I should get the actual variable. I mean, why #instVarNames workds but #instVarNamed: doesn't? That is inconsistent.
to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)
but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class.
The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there.
Yes I know but we could override Object methods to make sense on Class/Metaclass Stef
unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..
participants (7)
-
Camillo Bruni -
Fernando Olivero -
Guido Chari -
Guillermo Polito -
Igor Stasenko -
Mariano Martinez Peck -
Stéphane Ducasse