On Dec 23, 2008, at 11:19 PM, Keith Hodges wrote:

> Stéphane Ducasse wrote:
>>
>> No it should follow well specified rules.
> Ultimately the compiler is not really compiling smalltalk, it is
> compiling some primitive concepts that Behaviour and friends turn in  
> to
> smalltalk by virtue of their implementation. There is nothing stopping
> anyone one defining another language with entirely different
> conventions. So the compiler should not enforce smalltalk rules. If
> Behaviour/ClassDescription wants to enforce some rules then that is
> Behaviour's business and it should be overrideable.

sorry I do not buy that. Do you know why Smalltalk 76 did not work
because classes could change their syntax.

>> Else this is the mess.
>> In Smalltalk uppercase are for global variables and lowercase for
>> private.
>> Class instance variables are only accessible from the metaclass
>> methods so they should be
>> lowercase.
>>
>> Now if a lousy compiler allows them this is the problem.
>>
>>
> Not at all, there are times when you might want an instance variable  
> to
> have an uppercase name.

When show it to me for real.
Tell me that this is because you want to connect to a C library or  
something like
that but not for Singleton.

> These kind of bending of the rules are
> particularly useful when using Smalltalk as a DSL.

Show me an example.
We are talking about **variable** and in Smalltalk you cannot access  
them
there is no access operator so for the DSL story it does not work.

You see for the method selectors, I think that we should allow _
so that we can interoperate more easily.  But for private method only  
accessible in
side a method I do not see the point.

> It is only a convention so I do not think that the compiler should  
> enforce it.


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


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

Reply via email to