Smalltalk vs SmalltalkImage current woes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Smalltalk vs SmalltalkImage current woes

Igor Stasenko
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Klaus D. Witzel
On Fri, 24 Jul 2009 12:27:36 +0200, 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).

This part will not work, check yourself:

  (Smalltalk associationAt: #Smalltalk) inspect

/Klaus

> Now, Smalltalk == SmalltalkImage current and everyone is happy:
>  - dictionary lives in separate ivar,
>  - fat & boring housekeeping stuff lives in SmalltalkImage instance.
>
> What you think?
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Smalltalk vs SmalltalkImage current woes

Igor Stasenko
2009/7/24 Klaus D. Witzel <[hidden email]>:

> On Fri, 24 Jul 2009 12:27:36 +0200, 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).
>
> This part will not work, check yourself:
>
>  (Smalltalk associationAt: #Smalltalk) inspect
>
in what way it wont work?
I can implement #associationAt: in SmalltalkImage class, to proxy it
to globals ivar. What's wrong with it?
Or do you mean, that we will end up with the need of proxying all
Collection protocol methods?
There always can be more radical solutions, like proxying rest of
stuff through DNU handler :)

> /Klaus
>
>> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Klaus D. Witzel
On Fri, 24 Jul 2009 12:39:07 +0200, Igor Stasenko wrote:

> 2009/7/24 Klaus D. Witzel :
...
>>> So, what i'm proposing:
...
>>> then simply:
>>> Smalltalk at: #Smalltalk put: (SmalltalkImage current).
>>
>> This part will not work, check yourself:
>>
>>  (Smalltalk associationAt: #Smalltalk) inspect
>>
> in what way it wont work?

I was responding to a practical issue, not a conceptual one; try

  Smalltalk at: #Smalltalk put: Smalltalk

then you should see why that's not possible.

> I can implement #associationAt: in SmalltalkImage class, to proxy it
> to globals ivar. What's wrong with it?

With #associationAt: in SmalltalkImage? nothing, if it still makes sense.

> Or do you mean, that we will end up with the need of proxying all
> Collection protocol methods?

Some of them: yes; unless you get rid of "Dictionary" users' view.

> There always can be more radical solutions, like proxying rest of
> stuff through DNU handler :)

:)

>> /Klaus


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Igor Stasenko
2009/7/24 Klaus D. Witzel <[hidden email]>:

> On Fri, 24 Jul 2009 12:39:07 +0200, Igor Stasenko wrote:
>
>> 2009/7/24 Klaus D. Witzel :
> ...
>>>> So, what i'm proposing:
> ...
>>>> then simply:
>>>> Smalltalk at: #Smalltalk put: (SmalltalkImage current).
>>>
>>> This part will not work, check yourself:
>>>
>>>  (Smalltalk associationAt: #Smalltalk) inspect
>>>
>> in what way it wont work?
>
> I was responding to a practical issue, not a conceptual one; try
>
>  Smalltalk at: #Smalltalk put: Smalltalk
>
> then you should see why that's not possible.
>
I don't see how this can be a barrier of any sort for a real hacker:

(Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk -> Smalltalk).

Smalltalk at: #Smalltalk put: Smalltalk

There are numerous ways how to get around this ;)
Btw, this is another reason to not expose messages like
#associationAt: to users.
Alas, associations is used by compiler. :(

>> I can implement #associationAt: in SmalltalkImage class, to proxy it
>> to globals ivar. What's wrong with it?
>
> With #associationAt: in SmalltalkImage? nothing, if it still makes sense.
>
>> Or do you mean, that we will end up with the need of proxying all
>> Collection protocol methods?
>
> Some of them: yes; unless you get rid of "Dictionary" users' view.
>
>> There always can be more radical solutions, like proxying rest of
>> stuff through DNU handler :)
>
> :)
>
>>> /Klaus
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Klaus D. Witzel
On Fri, 24 Jul 2009 13:53:47 +0200, Igor Stasenko wrote:

> 2009/7/24 Klaus D. Witzel :
...

>> I was responding to a practical issue, not a conceptual one; try
>>
>>  Smalltalk at: #Smalltalk put: Smalltalk
>>
>> then you should see why that's not possible.
>>
> I don't see how this can be a barrier of any sort for a real hacker:
>
> (Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk ->  
> Smalltalk).
>
> Smalltalk at: #Smalltalk put: Smalltalk
>
> There are numerous ways how to get around this ;)

Have you considered rehash, .image save & load ? I've thought about  
replacing (Smalltalk associationAt: #Smalltalk)'s value many times and  
don't want to risk other people's .images just because of *any* silly  
mistake. That's why I'm interested in solutions to the practical side.

> Btw, this is another reason to not expose messages like
> #associationAt: to users.

Yes, one reason is: do not expose #pointersTo:, since then #associationAt:  
can be simulated. And just another one: do not expose #someObject or  
#nextObject ( & friends), since then #pointersTo: can be simulated.  
(cough) back to Smalltalk? :)

> Alas, associations is used by compiler. :(

Sure.

/Klaus


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Smalltalk vs SmalltalkImage current woes

Igor Stasenko
2009/7/24 Klaus D. Witzel <[hidden email]>:

> On Fri, 24 Jul 2009 13:53:47 +0200, Igor Stasenko wrote:
>
>> 2009/7/24 Klaus D. Witzel :
>
> ...
>>>
>>> I was responding to a practical issue, not a conceptual one; try
>>>
>>>  Smalltalk at: #Smalltalk put: Smalltalk
>>>
>>> then you should see why that's not possible.
>>>
>> I don't see how this can be a barrier of any sort for a real hacker:
>>
>> (Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk ->
>> Smalltalk).
>>
>> Smalltalk at: #Smalltalk put: Smalltalk
>>
>> There are numerous ways how to get around this ;)
>
> Have you considered rehash, .image save & load ?

Since i'm not touching the key - #Smalltalk, such change is immune
from potential hashing issues.
And yes, i saved & loaded image after this brutal hack. It works as usual.

> I've thought about
> replacing (Smalltalk associationAt: #Smalltalk)'s value many times and don't
> want to risk other people's .images just because of *any* silly mistake.
> That's why I'm interested in solutions to the practical side.
>
well this could be done once, tested & shipped with new "core" image.
So you never need to be bothered with this again.

>> Btw, this is another reason to not expose messages like
>> #associationAt: to users.
>
> Yes, one reason is: do not expose #pointersTo:, since then #associationAt:
> can be simulated. And just another one: do not expose #someObject or
> #nextObject ( & friends), since then #pointersTo: can be simulated. (cough)
> back to Smalltalk? :)
>

Right, lets better discuss the pros and cons of such change instead of
 harms to Smalltalk association :)

>> Alas, associations is used by compiler. :(
>
> Sure.
>
> /Klaus
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

David Goehrig
In reply to this post by Igor Stasenko


On Fri, Jul 24, 2009 at 6:27 AM, Igor Stasenko <[hidden email]> wrote:

Now, Smalltalk == SmalltalkImage current and everyone is happy:
 - dictionary lives in separate ivar,
 - fat & boring housekeeping stuff lives in SmalltalkImage instance.

What you think?

I particularly like this idea from the standpoint of delivering a modules that exist within their own context.  It is actually not that dissimilar from Forth systems that use different vocabs to support multiple incompatible applications at the same time. 

Something like this would solve one of the problems I've been running into recently, where some code keeps mucking up the SystemDictionary's associations causing the Compiler to error out.  

Dave


--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Adrian Lienhard
In reply to this post by Igor Stasenko
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.

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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Stéphane Ducasse
In reply to this post by Igor Stasenko
Smalltalk is a dictionary namespace
not a shit place full of crap.

This is why we started to clean SystemDictionary
and people started to complain and we stop.

>
> 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?

Yes this was the solution we envision to keep people happy.
And one day cut the backlink.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Stéphane Ducasse
In reply to this post by Adrian Lienhard

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
>> [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
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk vs SmalltalkImage current woes

Igor Stasenko
In reply to this post by Stéphane Ducasse
2009/7/25 Stéphane Ducasse <[hidden email]>:
> Smalltalk is a dictionary namespace
> not a shit place full of crap.
>

Agree, this is why i proposing a consensus: Keep dictionary aside of shit,
and at same time live with what we currently have :)

> This is why we started to clean SystemDictionary
> and people started to complain and we stop.
>>
>> 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?
>
> Yes this was the solution we envision to keep people happy.
> And one day cut the backlink.
>
> Stef
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project