On Jul 24, 2009, at 8:22 PM, Adrian Lienhard wrote:

> I also like the idea since I always loose a few seconds to figure out
> where some method, like vmStatisticsReportString, is located. There
> are at least three different selectors used to access a singleton
> instance:
>
> SmalltalkImage current
> SystemNavigation default
> SystemChangeNotifier uniqueInstance
>
> I just can't remember them.

We could be consistent but havgin Smalltalk point to each of them is  
not a solution since the client code
will still not distinguish between its really provider.

Stef


>
> Adrian
>
> On Jul 24, 2009, at 12:27 , Igor Stasenko wrote:
>
>> I am currently using the Cuis, which doesn't having a 'SmalltalkImage
>> current' refactoring..
>> And this difference is a bit frustrating to me, especially when code
>> which have to be ported from Squeak,
>> i need to visit all the places and fix the references.
>>
>> I was not here when this change was introduced, and you maybe know ,
>> that i'm a heated enemy of global state.
>> But i understand the reasoning of dissection the Smalltalk dictionary
>> of globals from the rest of service methods & additional state,
>> which is needed and which were putted in SmalltalkImage class.
>>
>> But the more i thinking about it, the more i feel that this
>> 'dissection' can be done in least intrusive way which is much
>> friendlier to 'old ways'
>> but also plays well with 'current ways'.
>>
>> So, what i'm proposing:
>>
>> - make a dictionary of globals a pure dictionary, without any extra
>> unrelated methods.
>> - completely move all fat stuff into SmalltalkImage from
>> SystemDictionary class
>> - add 'globals' ivar to SmalltalkImage class , and add proxy methods
>> for accessing the dictionary, like #at: #at:put: etc.
>>
>> then simply:
>> Smalltalk at: #Smalltalk put: (SmalltalkImage current).
>>
>> Now, Smalltalk == SmalltalkImage current and everyone is happy:
>> - dictionary lives in separate ivar,
>> - fat & boring housekeeping stuff lives in SmalltalkImage instance.
>>
>> What you think?
>>
>> -- 
>> 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

Reply via email to