Smalltalk at: #Foo - needs clarification
Locked
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Smalltalk at: #Foo - needs clarification
|
|
On Oct 6, 2010, at 5:30 PM, Fernando olivero wrote: > > On Oct 6, 2010, at 4:36 PM, stephane ducasse 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? >> >> legacy you said! Let us move on. We keep to help people migrating. >> Now we should avoid it as much as possible even Smalltalk globals at:. It should be more >> self class environment at: >> >> In VisualWorks I'm not sure that Smalltalk at: make sense. > > I've been using: > > Smalltalk globals classNamed: aString. > > IMO It's better from a conceptual view because > 1. it breaks the class-symbol binding, > 2. and a Dictionary-like implementation for lookup. > > > Fernando _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Smalltalk at: #Foo - needs clarification
|
|
In reply to this post by Igor Stasenko
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
|
|
On 6 October 2010 19:08, Andreas Raab <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
|
|
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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] 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 <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
|
|
In reply to this post by Igor Stasenko
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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] > 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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
|
|
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: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Wednesday, October 06, 2010 6:01 PM To: [hidden email] 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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] > 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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |