[Pharo-project] Point name Point class name are not both symbol
Hi I was wondering if it would make sense to have Point name Point class name both returning a symbol and not in one case a symbol and the other a string. Stef
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I was wondering if it would make sense to have     Point name     Point class name     both returning a symbol and not in one case a symbol and the other a string.
To my understanding, there's only classes which obliged to be identified by name. Metaclasses don't need to have one, and actually free to answer anything they want.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Dec 25, 2009, at 3:39 PM, Igor Stasenko wrote:
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I was wondering if it would make sense to have Point name Point class name both returning a symbol and not in one case a symbol and the other a string.
To my understanding, there's only classes which obliged to be identified by name. Metaclasses don't need to have one, and actually free to answer anything they want.
I do not think so and be consistent would be good
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I On Friday, December 25, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 25, 2009, at 3:39 PM, Igor Stasenko wrote:
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I was wondering if it would make sense to have     Point name     Point class name     both returning a symbol and not in one case a symbol and the other a string.
To my understanding, there's only classes which obliged to be identified by name. Metaclasses don't need to have one, and actually free to answer anything they want.
I do not think so and be consistent would be good
I don't think that the name of a metaclass is used at all, and I can't think of a situation where the metaclass name would be useful (other than in the inspector). RB, OB and MC all do "aBehavior theNonMetaclass name". Also the metaclass name is quite inefficient for lookups, because it is a derived value. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I do not think so and be consistent would be good
I don't think that the name of a metaclass is used at all, and I can't think of a situation where the metaclass name would be useful (other than in the inspector). RB, OB and MC all do "aBehavior theNonMetaclass name". Also the metaclass name is quite inefficient for lookups, because it is a derived value.
I have a simple scenario aPackage addClassNamed: vs aPackage addClassNamed: meta: aBoolean of course may be I trying to provide a too large interface and I should only focus on aPackage addClass: because there I always get a class and I can ask its name. but I think that people may want to reorganize package may be without having the class loaded. So even if we cannot/should not too much with metaclass, having a symbol instead of a string would be good.
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 25, 2009, at 3:39 PM, Igor Stasenko wrote:
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I was wondering if it would make sense to have     Point name     Point class name     both returning a symbol and not in one case a symbol and the other a string.
To my understanding, there's only classes which obliged to be identified by name. Metaclasses don't need to have one, and actually free to answer anything they want.
I do not think so and be consistent would be good
The need to have class names comes from using the global namespace: (Smalltalk at: ConsistentClass name) == ConsistentClass metaclasses is not part of global namespace and therefore don't required to have some constraints in while answering #name message. Actually, it could answer 'ClassName metaclass' , or just 'a Metaclass' any form is acceptable. I'd rather punish those, who in own code expecting that metaclasses should answer something which can be parsed for detecting a class name!
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/12/25 Igor Stasenko <siguctua@gmail.com>:
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 25, 2009, at 3:39 PM, Igor Stasenko wrote:
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I was wondering if it would make sense to have     Point name     Point class name     both returning a symbol and not in one case a symbol and the other a string.
To my understanding, there's only classes which obliged to be identified by name. Metaclasses don't need to have one, and actually free to answer anything they want.
I do not think so and be consistent would be good
The need to have class names comes from using the global namespace:
(Smalltalk at: ConsistentClass name) == ConsistentClass
metaclasses is not part of global namespace and therefore don't required to have some constraints in while answering #name message.
Actually, it could answer 'ClassName metaclass' , or just 'a Metaclass' any form is acceptable. I'd rather punish those, who in own code expecting that metaclasses should answer something which can be parsed for detecting a class name!
Because the right form of accessing the name of class is: classOrMetaClass theClassSide name and right form of testing if behavior is metaclass is object isBehavior and: [ object isMeta ] but not: object name endsWith:'class' :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Because the right form of accessing the name of class is:
classOrMetaClass theClassSide name
and right form of testing if behavior is metaclass is
object isBehavior and: [ object isMeta ]
but not:
object name endsWith:'class'
indeed now what do you do if you do not want to have to load a class in memory to manipulate a group of them like a package... you end up doing pseudoClass.... why not but there is nothing that is that dogmatic. Stef
The need to have class names comes from using the global namespace:
(Smalltalk at: ConsistentClass name) == ConsistentClass
metaclasses is not part of global namespace and therefore don't required to have some constraints in while answering #name message.
Actually, it could answer 'ClassName metaclass' , or just 'a Metaclass' any form is acceptable.
No what you are saying is dogmatic. So far the metamodel of smalltalk is simple just class, packages does not even exist but as soons as you want to have a way to manipulate classes, you can manipulate metaclass and I do not know you but me I like when I want a class extension on a metaclass that it does not end up on the instance side.
I'd rather punish those, who in own code expecting that metaclasses should answer something which can be parsed for detecting a class name!
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
The need to have class names comes from using the global namespace:
(Smalltalk at: ConsistentClass name) == ConsistentClass
metaclasses is not part of global namespace and therefore don't required to have some constraints in while answering #name message.
Actually, it could answer 'ClassName metaclass' , or just 'a Metaclass' any form is acceptable.
No what you are saying is dogmatic.
Nope. Its anti-dogmatic. I'm not putting any expectations on what #name of metaclass should answer.
So far the metamodel of smalltalk is simple just class, packages does not even exist but as soons as you want to have a way to manipulate classes, you can manipulate metaclass and I do not know you but me I like when I want a class extension on a metaclass that it does not end up on the instance side.
I don't see a straight correspondence of this with #name implementation. Sure thing, i am both hands for easy & flexible manipulation of classes & metaclasses. So, maybe let's duscuss, what problem you encountered, and try to pick best solution(s). As i understand you trying to build a class meta-model in memory, but don't want to expose it to system, until it will be ready for installing.
I'd rather punish those, who in own code expecting that metaclasses should answer something which can be parsed for detecting a class name!
-- Best regards, Igor Stasenko AKA sig.
I'm just developing a real package class. And I keep class names because the classBuilder can recreate class instances under my foot.... So I can do aPack addClassNamed: aName aPack addClass: aClass (my favorite solution) Stef
2009/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I'm just developing a real package class. And I keep class names because the classBuilder can recreate class instances under my foot.... So I can do     aPack addClassNamed: aName
    aPack addClass: aClass  (my favorite solution)
i made own draft package classes, and my favorite is: add: object "Add object to receiver contents" (self includes: object) ifTrue: [ ^ object ]. (self canInclude: object) ifFalse: [ ^ self error: 'Given object can''t be included into package' ]. ^ contents add: object. ;) If you want , i can send you the code, maybe some of my ideas would be useful.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Stéphane Ducasse <stephane.ducasse@...> writes:
I was wondering if it would make sense to have Point name Point class name both returning a symbol and not in one case a symbol and the other a string.
To my understanding, the role of a symbol is to be a speed-optimized identifier (of either a class or method) and #'Point class' is not an identifier but an expression which does not evaluate faster when being a symbol. Also creating too many symbols might harm system performance. I learned that the hard way with Moose, it used to use symbols everywhere and eventually it would take 10 seconds to open autocompletion. So I am always reluctant to make too many symbols. --AA
Maybe you've also run into the problem with the symbol table that had very bad performance characteristics: http://code.google.com/p/pharo/issues/detail?id=1047 It was fixed in Pharo last summer. Adrian On Dec 25, 2009, at 22:45 , Adrian Kuhn wrote:
Stéphane Ducasse <stephane.ducasse@...> writes:
I was wondering if it would make sense to have Point name Point class name both returning a symbol and not in one case a symbol and the other a string.
To my understanding, the role of a symbol is to be a speed-optimized identifier (of either a class or method) and #'Point class' is not an identifier but an expression which does not evaluate faster when being a symbol.
Also creating too many symbols might harm system performance. I learned that the hard way with Moose, it used to use symbols everywhere and eventually it would take 10 seconds to open autocompletion. So I am always reluctant to make too many symbols.
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Adrian Kuhn -
Adrian Lienhard -
Igor Stasenko -
Lukas Renggli -
Stéphane Ducasse