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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/25 Stéphane Ducasse <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Dec 25, 2009, at 3:39 PM, Igor Stasenko wrote:

I do not think so and be consistent would be good

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I

On Friday, December 25, 2009, Stéphane Ducasse
<[hidden email]> wrote:
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/25 Stéphane Ducasse <[hidden email]>:
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!




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/25 Igor Stasenko <[hidden email]>: 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'
:)



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>
>> 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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/25 Stéphane Ducasse <[hidden email]>:
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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/25 Stéphane Ducasse <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project