[Pharo-project] Smalltalk at: #Foo - needs clarification
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? -- Best regards, Igor Stasenko AKA sig.
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. Cheers, - Andreas
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.
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. 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
participants (3)
-
Andreas Raab -
Igor Stasenko -
Schwab,Wilhelm K