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: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Wednesday, October 06, 2010 6:01 PM To: [email protected] 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: [email protected] > [[email protected]] On Behalf Of Igor Stasenko > [[email protected]] > 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 <[email protected]> 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 > [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 _______________________________________________ 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
