Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
This is why the image does not use Smalltalk at: but the at: method is still defined in SmalltalkImage.
Stef,
You raise a good point about helping to improve code, and I would MUCH rather see us try "aClass environment" for a while before introducing name spaces. Dolphin started leaning toward environments a long time ago, and suddenly "class names" were messages to the environment, and I was completely blown away by the potential power of it.
I started in 2002 to remove hardcoded Smalltalk at: and replace them by self class environment for the reason that having the possibility to have different systemDictionary instance can help us for: bootstrapping the compiler, building atomic laoding like VW for example.
So, I'm very open to the idea. However, I don't see any harm in ( Smalltalk at:#SomethingNotYetInstalled ), which I have had to use extensively in Migrate's image building code. Is there a better way to do the same thing?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, October 06, 2010 12:31 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
On 6 October 2010 19:08, Andreas Raab <andreas.raab@gmx.de> wrote:
On 10/6/2010 6:58 AM, Igor Stasenko wrote:
Hello,
just wanna ask, is this part of API will be deprecated in future? (in Pharo, it put under 'to clean later' category).
And if yes, then what will be correct (dialect-agnostic) way to access globals?
Smalltalk globals at: #Foo ?
I thought that #at: #at:put: (and some others) historically is a part of Smalltalk protocol, and should stay there to support legacy code and cross-dialect code.
What you thoughts about it?
The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should remain in Smalltalk for compatibility. Then it's a matter of where that request is being delegated.
Yes, i am also thinking that for compatibility it should stay.
Then i think in modern code, a most future-proof way is
self class environment at: #Foo
since it completely avoids any kind of early-binding.
Cheers, - Andreas
-- 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
Stef, Good enough, but it sounded like a higher level of cleaning was on the way?? Some of the code that I have using "Smalltalk at:" originally expected a SystemDictionary. I have no problem with implementation changes, and I like the #environment idea. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, October 06, 2010 6:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification This is why the image does not use Smalltalk at: but the at: method is still defined in SmalltalkImage.
Stef,
You raise a good point about helping to improve code, and I would MUCH rather see us try "aClass environment" for a while before introducing name spaces. Dolphin started leaning toward environments a long time ago, and suddenly "class names" were messages to the environment, and I was completely blown away by the potential power of it.
I started in 2002 to remove hardcoded Smalltalk at: and replace them by self class environment for the reason that having the possibility to have different systemDictionary instance can help us for: bootstrapping the compiler, building atomic laoding like VW for example.
So, I'm very open to the idea. However, I don't see any harm in ( Smalltalk at:#SomethingNotYetInstalled ), which I have had to use extensively in Migrate's image building code. Is there a better way to do the same thing?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, October 06, 2010 12:31 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
On 6 October 2010 19:08, Andreas Raab <andreas.raab@gmx.de> wrote:
On 10/6/2010 6:58 AM, Igor Stasenko wrote:
Hello,
just wanna ask, is this part of API will be deprecated in future? (in Pharo, it put under 'to clean later' category).
And if yes, then what will be correct (dialect-agnostic) way to access globals?
Smalltalk globals at: #Foo ?
I thought that #at: #at:put: (and some others) historically is a part of Smalltalk protocol, and should stay there to support legacy code and cross-dialect code.
What you thoughts about it?
The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should remain in Smalltalk for compatibility. Then it's a matter of where that request is being delegated.
Yes, i am also thinking that for compatibility it should stay.
Then i think in modern code, a most future-proof way is
self class environment at: #Foo
since it completely avoids any kind of early-binding.
Cheers, - Andreas
-- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Schwab,Wilhelm K -
Stéphane Ducasse