SmalltalkImage current vs. Smalltalk

> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>>
>> Hi,
>>
>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>:
>>>
>>> Consequently I'm going to completely ignore any forward-looking
>>> proposals and simply state that the current count is 3 votes for the
>>> first variant (Phil, David, Bert) and 1 vote for the second variant
>>> (Igor).
>>
>> here's another for "Smalltalk", then.
>
> That choice doesn't exist :-) You can vote for:
>
> a) Smalltalk class == SystemDictionary, or
>
> b) Smalltalk class == SmalltalkImage
>
> Cheers,
>  - Andreas
>
>

> 2010/3/3 Andreas Raab<[hidden email]>:
>> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>>>
>>> Hi,
>>>
>>> Am 03.03.2010 um 03:41 schrieb Andreas Raab<[hidden email]>:
>>>>
>>>> Consequently I'm going to completely ignore any forward-looking
>>>> proposals and simply state that the current count is 3 votes for the
>>>> first variant (Phil, David, Bert) and 1 vote for the second variant
>>>> (Igor).
>>>
>>> here's another for "Smalltalk", then.
>>
>> That choice doesn't exist :-) You can vote for:
>>
>> a) Smalltalk class == SystemDictionary, or
>>
>> b) Smalltalk class == SmalltalkImage
>>
>> Cheers,
>>   - Andreas
>>
>>
>
> I vote for b).
>
> After discussing this with Stephane Ducasse, I quite agree on this scheme:
>
> SmalltalkImage should better be renamed System.
> System soleInstance = Smalltalk.
> Of course an optional bakward compatibility module would define
> SmalltalkImage current

> On 3/3/2010 5:57 AM, Nicolas Cellier wrote:
>>
>> 2010/3/3 Andreas Raab<[hidden email]>:
>>>
>>> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am 03.03.2010 um 03:41 schrieb Andreas Raab<[hidden email]>:
>>>>>
>>>>> Consequently I'm going to completely ignore any forward-looking
>>>>> proposals and simply state that the current count is 3 votes for the
>>>>> first variant (Phil, David, Bert) and 1 vote for the second variant
>>>>> (Igor).
>>>>
>>>> here's another for "Smalltalk", then.
>>>
>>> That choice doesn't exist :-) You can vote for:
>>>
>>> a) Smalltalk class == SystemDictionary, or
>>>
>>> b) Smalltalk class == SmalltalkImage
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>
>> I vote for b).
>>
>> After discussing this with Stephane Ducasse, I quite agree on this scheme:
>>
>> SmalltalkImage should better be renamed System.
>> System soleInstance = Smalltalk.
>> Of course an optional bakward compatibility module would define
>> SmalltalkImage current
>
> The main thing this does is to create a *third* path that we'll have to
> support for eternity. I fail to see how "System soleInstance" is any better
> than "SmalltalImage current".
>

>>> After discussing this with Stephane Ducasse, I quite agree on this scheme:
>>>
>>> SmalltalkImage should better be renamed System.
>>> System soleInstance = Smalltalk.
>>> Of course an optional bakward compatibility module would define
>>> SmalltalkImage current
>>
>> The main thing this does is to create a *third* path that we'll have to
>> support for eternity. I fail to see how "System soleInstance" is any better
>> than "SmalltalImage current".
>>
>
> Why would you write System soleInstance?
> You will just write Smalltalk.

>> Seriously, if we want to move this stuff forward we should be starting by
>> having a moratorium on adding new methods to the old places and rather
>> discuss where *new methods* should live. This way we learn over some period
>> what works and what doesn't and if we're happy with the outcome then we move
>> a few more bits to those places. The approach of "let's just fix this
>> problem once and forever" simply does not work here because the solution
>> space is too big.
>>
>
> Using a message indirection like Smalltalk vm certainly helps.
> But sure, it does not solve every problem,
> One day or the other, we will want to change the level of abstraction
> for sure...
>
>> Concretely speaking, what would be alternative places for the cleanup
>> methods that I just added, and why? Where would you expect them and why? If
>> we have a good place we might start moving a few of the other housekeeping
>> methods over there. To me, this is a much more fruitful direction than the
>> above.
>>
>
> I would start with minimal changes and gradually introduce indirection messages.
> Then slowly deprecate message, and provide optional compatibility modules.
> But there, I always prefer a deeper analysis on true code :)
>
> Nicolas
>
>> Cheers,
>>   - Andreas
>>
>>
>
>

> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>
>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>> scheme:
>>>>
>>>> SmalltalkImage should better be renamed System.
>>>> System soleInstance = Smalltalk.
>>>> Of course an optional bakward compatibility module would define
>>>> SmalltalkImage current
>>>
>>> The main thing this does is to create a *third* path that we'll have to
>>> support for eternity. I fail to see how "System soleInstance" is any
>>> better
>>> than "SmalltalImage current".
>>>
>>
>> Why would you write System soleInstance?
>> You will just write Smalltalk.
>
> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
> that rewrites all references to SmalltalkImage current with System
> soleInstance :-) Never mind then.
>
>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>> reflect that Smalltalk is the soleInstance of System.
>> And we don't have to rename soleInstance either, it was just for
>> explaining the concept.
>
> Yes, that's a significant part of my motivation for option #2 as well.
> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
> think (although it doesn't really hurt either).
>

> Hm ... now that I've been thinking about it I'm starting to lean for #2
> myself a little more.
>
> Cheers,
>  - Andreas
>
>>> Seriously, if we want to move this stuff forward we should be starting by
>>> having a moratorium on adding new methods to the old places and rather
>>> discuss where *new methods* should live. This way we learn over some
>>> period
>>> what works and what doesn't and if we're happy with the outcome then we
>>> move
>>> a few more bits to those places. The approach of "let's just fix this
>>> problem once and forever" simply does not work here because the solution
>>> space is too big.
>>>
>>
>> Using a message indirection like Smalltalk vm certainly helps.
>> But sure, it does not solve every problem,
>> One day or the other, we will want to change the level of abstraction
>> for sure...
>>
>>> Concretely speaking, what would be alternative places for the cleanup
>>> methods that I just added, and why? Where would you expect them and why?
>>> If
>>> we have a good place we might start moving a few of the other
>>> housekeeping
>>> methods over there. To me, this is a much more fruitful direction than
>>> the
>>> above.
>>>
>>
>> I would start with minimal changes and gradually introduce indirection
>> messages.
>> Then slowly deprecate message, and provide optional compatibility modules.
>> But there, I always prefer a deeper analysis on true code :)
>>
>> Nicolas
>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>
>>
>
>
>

> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>
>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>> scheme:
>>>>>
>>>>> SmalltalkImage should better be renamed System.
>>>>> System soleInstance = Smalltalk.
>>>>> Of course an optional bakward compatibility module would define
>>>>> SmalltalkImage current
>>>>
>>>> The main thing this does is to create a *third* path that we'll have to
>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>> better
>>>> than "SmalltalImage current".
>>>>
>>>
>>> Why would you write System soleInstance?
>>> You will just write Smalltalk.
>>
>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>> that rewrites all references to SmalltalkImage current with System
>> soleInstance :-) Never mind then.
>>
>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>> reflect that Smalltalk is the soleInstance of System.
>>> And we don't have to rename soleInstance either, it was just for
>>> explaining the concept.
>>
>> Yes, that's a significant part of my motivation for option #2 as well.
>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>> think (although it doesn't really hurt either).
>>
>
> It hurts, because there is no documentation (which is mostly our case
> today), and its easy to shoot yourself in own foot
> like using #removeKey: instead of #removeClass: and things like that.
> Exposing a low-level protocol to the universe is just plain wrong!
> Not for you as an expert, but think about newcomers.
> Instead of telling users 'please don't use this, or you will be
> punished', it is much better to build things in a way,
> which will make them hard to abuse (or even better - there will be no
> need for abuses), but even if its sometimes needed,
> things should be organized in a such way, that there will be clear
> understanding what might happen, when he will bypass a  safeguards,
> because he will learn from a present architecture and so will think
> twice if he doing right thing.
>
> Needless to say, that we should discourage from using globals. That's
> why 'Smalltalk tools browse: #foo' is much better than
> 'ToolSet browse: #foo'. Because its ok, when you have single, well
> known root global, but when you having dozens of them scattered over
> image.. things become worse and worse.
>

>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>> myself a little more.
>>
>> Cheers,
>>  - Andreas
>>
>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>> having a moratorium on adding new methods to the old places and rather
>>>> discuss where *new methods* should live. This way we learn over some
>>>> period
>>>> what works and what doesn't and if we're happy with the outcome then we
>>>> move
>>>> a few more bits to those places. The approach of "let's just fix this
>>>> problem once and forever" simply does not work here because the solution
>>>> space is too big.
>>>>
>>>
>>> Using a message indirection like Smalltalk vm certainly helps.
>>> But sure, it does not solve every problem,
>>> One day or the other, we will want to change the level of abstraction
>>> for sure...
>>>
>>>> Concretely speaking, what would be alternative places for the cleanup
>>>> methods that I just added, and why? Where would you expect them and why?
>>>> If
>>>> we have a good place we might start moving a few of the other
>>>> housekeeping
>>>> methods over there. To me, this is a much more fruitful direction than
>>>> the
>>>> above.
>>>>
>>>
>>> I would start with minimal changes and gradually introduce indirection
>>> messages.
>>> Then slowly deprecate message, and provide optional compatibility modules.
>>> But there, I always prefer a deeper analysis on true code :)
>>>
>>> Nicolas
>>>
>>>> Cheers,
>>>>  - Andreas
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> 2010/3/3 Igor Stasenko <[hidden email]>:
>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>
>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>> scheme:
>>>>>>
>>>>>> SmalltalkImage should better be renamed System.
>>>>>> System soleInstance = Smalltalk.
>>>>>> Of course an optional bakward compatibility module would define
>>>>>> SmalltalkImage current
>>>>>
>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>> better
>>>>> than "SmalltalImage current".
>>>>>
>>>>
>>>> Why would you write System soleInstance?
>>>> You will just write Smalltalk.
>>>
>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>> that rewrites all references to SmalltalkImage current with System
>>> soleInstance :-) Never mind then.
>>>
>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>> reflect that Smalltalk is the soleInstance of System.
>>>> And we don't have to rename soleInstance either, it was just for
>>>> explaining the concept.
>>>
>>> Yes, that's a significant part of my motivation for option #2 as well.
>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>> think (although it doesn't really hurt either).
>>>
>>
>> It hurts, because there is no documentation (which is mostly our case
>> today), and its easy to shoot yourself in own foot
>> like using #removeKey: instead of #removeClass: and things like that.
>> Exposing a low-level protocol to the universe is just plain wrong!
>> Not for you as an expert, but think about newcomers.
>> Instead of telling users 'please don't use this, or you will be
>> punished', it is much better to build things in a way,
>> which will make them hard to abuse (or even better - there will be no
>> need for abuses), but even if its sometimes needed,
>> things should be organized in a such way, that there will be clear
>> understanding what might happen, when he will bypass a  safeguards,
>> because he will learn from a present architecture and so will think
>> twice if he doing right thing.
>>
>> Needless to say, that we should discourage from using globals. That's
>> why 'Smalltalk tools browse: #foo' is much better than
>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>> known root global, but when you having dozens of them scattered over
>> image.. things become worse and worse.
>>
>
> We could ask why memorizing a message name is simpler than memorizing
> a global name ?
> Well it's not.
>
> Unless we use poor semantics in class names (Framework Handler System
> Management.etc. are not so informative.keywords...).
> We feel forced to use such silly names because we are in a global namespace...
> For messages, the namespace is a bit more local.
>
> So why using a message would be better than a global ?
> -1) because of the tools: we get a well known entry point for
> browsing: Smalltalk
> -2) because the message can redirect to any object, eventually conditionnally
> -3) it is much easier to refactor code while maintaining
> compatibility: just change an implementor instead of many senders
> and we need to refactor when introducing new abstractions...
>

> Maybe some will see other advantages (security ?)
>
> Nicolas
>
>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>> myself a little more.
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>> having a moratorium on adding new methods to the old places and rather
>>>>> discuss where *new methods* should live. This way we learn over some
>>>>> period
>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>> move
>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>> problem once and forever" simply does not work here because the solution
>>>>> space is too big.
>>>>>
>>>>
>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>> But sure, it does not solve every problem,
>>>> One day or the other, we will want to change the level of abstraction
>>>> for sure...
>>>>
>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>> If
>>>>> we have a good place we might start moving a few of the other
>>>>> housekeeping
>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>> the
>>>>> above.
>>>>>
>>>>
>>>> I would start with minimal changes and gradually introduce indirection
>>>> messages.
>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>> But there, I always prefer a deeper analysis on true code :)
>>>>
>>>> Nicolas
>>>>
>>>>> Cheers,
>>>>>  - Andreas
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> On 4 March 2010 00:45, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/3 Igor Stasenko <[hidden email]>:
>>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>>
>>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>>> scheme:
>>>>>>>
>>>>>>> SmalltalkImage should better be renamed System.
>>>>>>> System soleInstance = Smalltalk.
>>>>>>> Of course an optional bakward compatibility module would define
>>>>>>> SmalltalkImage current
>>>>>>
>>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>>> better
>>>>>> than "SmalltalImage current".
>>>>>>
>>>>>
>>>>> Why would you write System soleInstance?
>>>>> You will just write Smalltalk.
>>>>
>>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>>> that rewrites all references to SmalltalkImage current with System
>>>> soleInstance :-) Never mind then.
>>>>
>>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>>> reflect that Smalltalk is the soleInstance of System.
>>>>> And we don't have to rename soleInstance either, it was just for
>>>>> explaining the concept.
>>>>
>>>> Yes, that's a significant part of my motivation for option #2 as well.
>>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>>> think (although it doesn't really hurt either).
>>>>
>>>
>>> It hurts, because there is no documentation (which is mostly our case
>>> today), and its easy to shoot yourself in own foot
>>> like using #removeKey: instead of #removeClass: and things like that.
>>> Exposing a low-level protocol to the universe is just plain wrong!
>>> Not for you as an expert, but think about newcomers.
>>> Instead of telling users 'please don't use this, or you will be
>>> punished', it is much better to build things in a way,
>>> which will make them hard to abuse (or even better - there will be no
>>> need for abuses), but even if its sometimes needed,
>>> things should be organized in a such way, that there will be clear
>>> understanding what might happen, when he will bypass a  safeguards,
>>> because he will learn from a present architecture and so will think
>>> twice if he doing right thing.
>>>
>>> Needless to say, that we should discourage from using globals. That's
>>> why 'Smalltalk tools browse: #foo' is much better than
>>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>>> known root global, but when you having dozens of them scattered over
>>> image.. things become worse and worse.
>>>
>>
>> We could ask why memorizing a message name is simpler than memorizing
>> a global name ?
>> Well it's not.
>>
>> Unless we use poor semantics in class names (Framework Handler System
>> Management.etc. are not so informative.keywords...).
>> We feel forced to use such silly names because we are in a global namespace...
>> For messages, the namespace is a bit more local.
>>
>> So why using a message would be better than a global ?
>> -1) because of the tools: we get a well known entry point for
>> browsing: Smalltalk
>> -2) because the message can redirect to any object, eventually conditionnally
>> -3) it is much easier to refactor code while maintaining
>> compatibility: just change an implementor instead of many senders
>> and we need to refactor when introducing new abstractions...
>>
> this is also means better modulatiry.
>
> -4) Because of the way of thinking. First thought, when you need
> something to do is: 'I need to find method',
> not 'I need a SystemNavigation to find a method'. This means, that
> initially, to describe our intent we using verbs, which characterizing
> what you going to do,  and only then we going to next question 'what
> is a proper tool to do that?'  or 'what object(s) should be used to do
> that?'. And in this way we are forming a message - selector is verb,
> and receiver is noun.

> And, obviously, because of that, first thing which one going do is to
> look for implementors of 'find' or 'findMethod', because it is really
> irrelevant who is implementor, once it satisfies the need. And so, it
> is not important to have a global with nice name which will reflect
> what it is used for or its potential behavior
> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
> much more important to have a properly named methods which
> implementing this behaivor.
>
>> Maybe some will see other advantages (security ?)
>>
>> Nicolas
>>
>>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>>> myself a little more.
>>>>
>>>> Cheers,
>>>>  - Andreas
>>>>
>>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>>> having a moratorium on adding new methods to the old places and rather
>>>>>> discuss where *new methods* should live. This way we learn over some
>>>>>> period
>>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>>> move
>>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>>> problem once and forever" simply does not work here because the solution
>>>>>> space is too big.
>>>>>>
>>>>>
>>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>>> But sure, it does not solve every problem,
>>>>> One day or the other, we will want to change the level of abstraction
>>>>> for sure...
>>>>>
>>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>>> If
>>>>>> we have a good place we might start moving a few of the other
>>>>>> housekeeping
>>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>>> the
>>>>>> above.
>>>>>>
>>>>>
>>>>> I would start with minimal changes and gradually introduce indirection
>>>>> messages.
>>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>>> But there, I always prefer a deeper analysis on true code :)
>>>>>
>>>>> Nicolas
>>>>>
>>>>>> Cheers,
>>>>>>  - Andreas
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> 2010/3/4 Igor Stasenko <[hidden email]>:
>> On 4 March 2010 00:45, Nicolas Cellier
>> <[hidden email]> wrote:
>>> 2010/3/3 Igor Stasenko <[hidden email]>:
>>>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>>>
>>>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>>>> scheme:
>>>>>>>>
>>>>>>>> SmalltalkImage should better be renamed System.
>>>>>>>> System soleInstance = Smalltalk.
>>>>>>>> Of course an optional bakward compatibility module would define
>>>>>>>> SmalltalkImage current
>>>>>>>
>>>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>>>> better
>>>>>>> than "SmalltalImage current".
>>>>>>>
>>>>>>
>>>>>> Why would you write System soleInstance?
>>>>>> You will just write Smalltalk.
>>>>>
>>>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>>>> that rewrites all references to SmalltalkImage current with System
>>>>> soleInstance :-) Never mind then.
>>>>>
>>>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>>>> reflect that Smalltalk is the soleInstance of System.
>>>>>> And we don't have to rename soleInstance either, it was just for
>>>>>> explaining the concept.
>>>>>
>>>>> Yes, that's a significant part of my motivation for option #2 as well.
>>>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>>>> think (although it doesn't really hurt either).
>>>>>
>>>>
>>>> It hurts, because there is no documentation (which is mostly our case
>>>> today), and its easy to shoot yourself in own foot
>>>> like using #removeKey: instead of #removeClass: and things like that.
>>>> Exposing a low-level protocol to the universe is just plain wrong!
>>>> Not for you as an expert, but think about newcomers.
>>>> Instead of telling users 'please don't use this, or you will be
>>>> punished', it is much better to build things in a way,
>>>> which will make them hard to abuse (or even better - there will be no
>>>> need for abuses), but even if its sometimes needed,
>>>> things should be organized in a such way, that there will be clear
>>>> understanding what might happen, when he will bypass a  safeguards,
>>>> because he will learn from a present architecture and so will think
>>>> twice if he doing right thing.
>>>>
>>>> Needless to say, that we should discourage from using globals. That's
>>>> why 'Smalltalk tools browse: #foo' is much better than
>>>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>>>> known root global, but when you having dozens of them scattered over
>>>> image.. things become worse and worse.
>>>>
>>>
>>> We could ask why memorizing a message name is simpler than memorizing
>>> a global name ?
>>> Well it's not.
>>>
>>> Unless we use poor semantics in class names (Framework Handler System
>>> Management.etc. are not so informative.keywords...).
>>> We feel forced to use such silly names because we are in a global namespace...
>>> For messages, the namespace is a bit more local.
>>>
>>> So why using a message would be better than a global ?
>>> -1) because of the tools: we get a well known entry point for
>>> browsing: Smalltalk
>>> -2) because the message can redirect to any object, eventually conditionnally
>>> -3) it is much easier to refactor code while maintaining
>>> compatibility: just change an implementor instead of many senders
>>> and we need to refactor when introducing new abstractions...
>>>
>> this is also means better modulatiry.
>>
>> -4) Because of the way of thinking. First thought, when you need
>> something to do is: 'I need to find method',
>> not 'I need a SystemNavigation to find a method'. This means, that
>> initially, to describe our intent we using verbs, which characterizing
>> what you going to do,  and only then we going to next question 'what
>> is a proper tool to do that?'  or 'what object(s) should be used to do
>> that?'. And in this way we are forming a message - selector is verb,
>> and receiver is noun.
>
> Well, not exactly here, we are complexifying the grammar a bit:
>
> Smalltalk vm
> Smalltalk commandLine
>
> This are just nouns at genitive case... The verb will follow.
>
> Nicolas
>

>> And, obviously, because of that, first thing which one going do is to
>> look for implementors of 'find' or 'findMethod', because it is really
>> irrelevant who is implementor, once it satisfies the need. And so, it
>> is not important to have a global with nice name which will reflect
>> what it is used for or its potential behavior
>> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
>> much more important to have a properly named methods which
>> implementing this behaivor.
>>
>>> Maybe some will see other advantages (security ?)
>>>
>>> Nicolas
>>>
>>>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>>>> myself a little more.
>>>>>
>>>>> Cheers,
>>>>>  - Andreas
>>>>>
>>>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>>>> having a moratorium on adding new methods to the old places and rather
>>>>>>> discuss where *new methods* should live. This way we learn over some
>>>>>>> period
>>>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>>>> move
>>>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>>>> problem once and forever" simply does not work here because the solution
>>>>>>> space is too big.
>>>>>>>
>>>>>>
>>>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>>>> But sure, it does not solve every problem,
>>>>>> One day or the other, we will want to change the level of abstraction
>>>>>> for sure...
>>>>>>
>>>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>>>> If
>>>>>>> we have a good place we might start moving a few of the other
>>>>>>> housekeeping
>>>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>>>> the
>>>>>>> above.
>>>>>>>
>>>>>>
>>>>>> I would start with minimal changes and gradually introduce indirection
>>>>>> messages.
>>>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>>>> But there, I always prefer a deeper analysis on true code :)
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>> Cheers,
>>>>>>>  - Andreas
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>

> 2010/3/4 Nicolas Cellier <[hidden email]>:
>> 2010/3/4 Igor Stasenko <[hidden email]>:
>>> On 4 March 2010 00:45, Nicolas Cellier
>>> <[hidden email]> wrote:
>>>> 2010/3/3 Igor Stasenko <[hidden email]>:
>>>>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>>>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>>>>
>>>>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>>>>> scheme:
>>>>>>>>>
>>>>>>>>> SmalltalkImage should better be renamed System.
>>>>>>>>> System soleInstance = Smalltalk.
>>>>>>>>> Of course an optional bakward compatibility module would define
>>>>>>>>> SmalltalkImage current
>>>>>>>>
>>>>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>>>>> better
>>>>>>>> than "SmalltalImage current".
>>>>>>>>
>>>>>>>
>>>>>>> Why would you write System soleInstance?
>>>>>>> You will just write Smalltalk.
>>>>>>
>>>>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>>>>> that rewrites all references to SmalltalkImage current with System
>>>>>> soleInstance :-) Never mind then.
>>>>>>
>>>>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>>>>> reflect that Smalltalk is the soleInstance of System.
>>>>>>> And we don't have to rename soleInstance either, it was just for
>>>>>>> explaining the concept.
>>>>>>
>>>>>> Yes, that's a significant part of my motivation for option #2 as well.
>>>>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>>>>> think (although it doesn't really hurt either).
>>>>>>
>>>>>
>>>>> It hurts, because there is no documentation (which is mostly our case
>>>>> today), and its easy to shoot yourself in own foot
>>>>> like using #removeKey: instead of #removeClass: and things like that.
>>>>> Exposing a low-level protocol to the universe is just plain wrong!
>>>>> Not for you as an expert, but think about newcomers.
>>>>> Instead of telling users 'please don't use this, or you will be
>>>>> punished', it is much better to build things in a way,
>>>>> which will make them hard to abuse (or even better - there will be no
>>>>> need for abuses), but even if its sometimes needed,
>>>>> things should be organized in a such way, that there will be clear
>>>>> understanding what might happen, when he will bypass a  safeguards,
>>>>> because he will learn from a present architecture and so will think
>>>>> twice if he doing right thing.
>>>>>
>>>>> Needless to say, that we should discourage from using globals. That's
>>>>> why 'Smalltalk tools browse: #foo' is much better than
>>>>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>>>>> known root global, but when you having dozens of them scattered over
>>>>> image.. things become worse and worse.
>>>>>
>>>>
>>>> We could ask why memorizing a message name is simpler than memorizing
>>>> a global name ?
>>>> Well it's not.
>>>>
>>>> Unless we use poor semantics in class names (Framework Handler System
>>>> Management.etc. are not so informative.keywords...).
>>>> We feel forced to use such silly names because we are in a global namespace...
>>>> For messages, the namespace is a bit more local.
>>>>
>>>> So why using a message would be better than a global ?
>>>> -1) because of the tools: we get a well known entry point for
>>>> browsing: Smalltalk
>>>> -2) because the message can redirect to any object, eventually conditionnally
>>>> -3) it is much easier to refactor code while maintaining
>>>> compatibility: just change an implementor instead of many senders
>>>> and we need to refactor when introducing new abstractions...
>>>>
>>> this is also means better modulatiry.
>>>
>>> -4) Because of the way of thinking. First thought, when you need
>>> something to do is: 'I need to find method',
>>> not 'I need a SystemNavigation to find a method'. This means, that
>>> initially, to describe our intent we using verbs, which characterizing
>>> what you going to do,  and only then we going to next question 'what
>>> is a proper tool to do that?'  or 'what object(s) should be used to do
>>> that?'. And in this way we are forming a message - selector is verb,
>>> and receiver is noun.
>>
>> Well, not exactly here, we are complexifying the grammar a bit:
>>
>> Smalltalk vm
>> Smalltalk commandLine
>>
>> This are just nouns at genitive case... The verb will follow.
>>

> Nicolas
>
>>> And, obviously, because of that, first thing which one going do is to
>>> look for implementors of 'find' or 'findMethod', because it is really
>>> irrelevant who is implementor, once it satisfies the need. And so, it
>>> is not important to have a global with nice name which will reflect
>>> what it is used for or its potential behavior
>>> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
>>> much more important to have a properly named methods which
>>> implementing this behaivor.
>>>
>>>> Maybe some will see other advantages (security ?)
>>>>
>>>> Nicolas
>>>>
>>>>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>>>>> myself a little more.
>>>>>>
>>>>>> Cheers,
>>>>>>  - Andreas
>>>>>>
>>>>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>>>>> having a moratorium on adding new methods to the old places and rather
>>>>>>>> discuss where *new methods* should live. This way we learn over some
>>>>>>>> period
>>>>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>>>>> move
>>>>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>>>>> problem once and forever" simply does not work here because the solution
>>>>>>>> space is too big.
>>>>>>>>
>>>>>>>
>>>>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>>>>> But sure, it does not solve every problem,
>>>>>>> One day or the other, we will want to change the level of abstraction
>>>>>>> for sure...
>>>>>>>
>>>>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>>>>> If
>>>>>>>> we have a good place we might start moving a few of the other
>>>>>>>> housekeeping
>>>>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>>>>> the
>>>>>>>> above.
>>>>>>>>
>>>>>>>
>>>>>>> I would start with minimal changes and gradually introduce indirection
>>>>>>> messages.
>>>>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>>>>> But there, I always prefer a deeper analysis on true code :)
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>  - Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>
>

> On 4 March 2010 01:50, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/4 Nicolas Cellier <[hidden email]>:
>>> 2010/3/4 Igor Stasenko <[hidden email]>:
>>>> On 4 March 2010 00:45, Nicolas Cellier
>>>> <[hidden email]> wrote:
>>>>> 2010/3/3 Igor Stasenko <[hidden email]>:
>>>>>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>>>>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>>>>>
>>>>>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>>>>>> scheme:
>>>>>>>>>>
>>>>>>>>>> SmalltalkImage should better be renamed System.
>>>>>>>>>> System soleInstance = Smalltalk.
>>>>>>>>>> Of course an optional bakward compatibility module would define
>>>>>>>>>> SmalltalkImage current
>>>>>>>>>
>>>>>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>>>>>> better
>>>>>>>>> than "SmalltalImage current".
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why would you write System soleInstance?
>>>>>>>> You will just write Smalltalk.
>>>>>>>
>>>>>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>>>>>> that rewrites all references to SmalltalkImage current with System
>>>>>>> soleInstance :-) Never mind then.
>>>>>>>
>>>>>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>>>>>> reflect that Smalltalk is the soleInstance of System.
>>>>>>>> And we don't have to rename soleInstance either, it was just for
>>>>>>>> explaining the concept.
>>>>>>>
>>>>>>> Yes, that's a significant part of my motivation for option #2 as well.
>>>>>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>>>>>> think (although it doesn't really hurt either).
>>>>>>>
>>>>>>
>>>>>> It hurts, because there is no documentation (which is mostly our case
>>>>>> today), and its easy to shoot yourself in own foot
>>>>>> like using #removeKey: instead of #removeClass: and things like that.
>>>>>> Exposing a low-level protocol to the universe is just plain wrong!
>>>>>> Not for you as an expert, but think about newcomers.
>>>>>> Instead of telling users 'please don't use this, or you will be
>>>>>> punished', it is much better to build things in a way,
>>>>>> which will make them hard to abuse (or even better - there will be no
>>>>>> need for abuses), but even if its sometimes needed,
>>>>>> things should be organized in a such way, that there will be clear
>>>>>> understanding what might happen, when he will bypass a  safeguards,
>>>>>> because he will learn from a present architecture and so will think
>>>>>> twice if he doing right thing.
>>>>>>
>>>>>> Needless to say, that we should discourage from using globals. That's
>>>>>> why 'Smalltalk tools browse: #foo' is much better than
>>>>>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>>>>>> known root global, but when you having dozens of them scattered over
>>>>>> image.. things become worse and worse.
>>>>>>
>>>>>
>>>>> We could ask why memorizing a message name is simpler than memorizing
>>>>> a global name ?
>>>>> Well it's not.
>>>>>
>>>>> Unless we use poor semantics in class names (Framework Handler System
>>>>> Management.etc. are not so informative.keywords...).
>>>>> We feel forced to use such silly names because we are in a global namespace...
>>>>> For messages, the namespace is a bit more local.
>>>>>
>>>>> So why using a message would be better than a global ?
>>>>> -1) because of the tools: we get a well known entry point for
>>>>> browsing: Smalltalk
>>>>> -2) because the message can redirect to any object, eventually conditionnally
>>>>> -3) it is much easier to refactor code while maintaining
>>>>> compatibility: just change an implementor instead of many senders
>>>>> and we need to refactor when introducing new abstractions...
>>>>>
>>>> this is also means better modulatiry.
>>>>
>>>> -4) Because of the way of thinking. First thought, when you need
>>>> something to do is: 'I need to find method',
>>>> not 'I need a SystemNavigation to find a method'. This means, that
>>>> initially, to describe our intent we using verbs, which characterizing
>>>> what you going to do,  and only then we going to next question 'what
>>>> is a proper tool to do that?'  or 'what object(s) should be used to do
>>>> that?'. And in this way we are forming a message - selector is verb,
>>>> and receiver is noun.
>>>
>>> Well, not exactly here, we are complexifying the grammar a bit:
>>>
>>> Smalltalk vm
>>> Smalltalk commandLine
>>>
>>> This are just nouns at genitive case... The verb will follow.
>>>
> It was about removing extra globals from use.
> Smalltalk vm version.  Smalltalk query implementorsOf: #foo
> is better than
> SmalltalkVm version. SystemNavigation implementorsOf: #foo
> because we using less globals :)
>

>>> Nicolas
>>>
>>
>> Just another thought: you might ask does it scale ?
>> No.
>> Having thousands of message or more indirections would just be bad...
>>   Smalltalk vm memory policy doSomething
>>
> will you prefer 'SmalltalkVMMemoryPolicy doSomething'? ;)
>
> The explosion of names have to happen somewhere, when you adding new
> functionality.
>
>> But the answer is:we don't want to scale !
>> We want a small manageable Kernel, don't we ?
>>
>
> indeed.
>
>> Nicolas
>>
>>>> And, obviously, because of that, first thing which one going do is to
>>>> look for implementors of 'find' or 'findMethod', because it is really
>>>> irrelevant who is implementor, once it satisfies the need. And so, it
>>>> is not important to have a global with nice name which will reflect
>>>> what it is used for or its potential behavior
>>>> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
>>>> much more important to have a properly named methods which
>>>> implementing this behaivor.
>>>>
>>>>> Maybe some will see other advantages (security ?)
>>>>>
>>>>> Nicolas
>>>>>
>>>>>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>>>>>> myself a little more.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>  - Andreas
>>>>>>>
>>>>>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>>>>>> having a moratorium on adding new methods to the old places and rather
>>>>>>>>> discuss where *new methods* should live. This way we learn over some
>>>>>>>>> period
>>>>>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>>>>>> move
>>>>>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>>>>>> problem once and forever" simply does not work here because the solution
>>>>>>>>> space is too big.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>>>>>> But sure, it does not solve every problem,
>>>>>>>> One day or the other, we will want to change the level of abstraction
>>>>>>>> for sure...
>>>>>>>>
>>>>>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>>>>>> If
>>>>>>>>> we have a good place we might start moving a few of the other
>>>>>>>>> housekeeping
>>>>>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>>>>>> the
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would start with minimal changes and gradually introduce indirection
>>>>>>>> messages.
>>>>>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>>>>>> But there, I always prefer a deeper analysis on true code :)
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>  - Andreas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> 2010/3/4 Igor Stasenko <[hidden email]>:
>> On 4 March 2010 01:50, Nicolas Cellier
>> <[hidden email]> wrote:
>>> 2010/3/4 Nicolas Cellier <[hidden email]>:
>>>> 2010/3/4 Igor Stasenko <[hidden email]>:
>>>>> On 4 March 2010 00:45, Nicolas Cellier
>>>>> <[hidden email]> wrote:
>>>>>> 2010/3/3 Igor Stasenko <[hidden email]>:
>>>>>>> On 3 March 2010 20:20, Andreas Raab <[hidden email]> wrote:
>>>>>>>> On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>>>>>>>>>>
>>>>>>>>>>> After discussing this with Stephane Ducasse, I quite agree on this
>>>>>>>>>>> scheme:
>>>>>>>>>>>
>>>>>>>>>>> SmalltalkImage should better be renamed System.
>>>>>>>>>>> System soleInstance = Smalltalk.
>>>>>>>>>>> Of course an optional bakward compatibility module would define
>>>>>>>>>>> SmalltalkImage current
>>>>>>>>>>
>>>>>>>>>> The main thing this does is to create a *third* path that we'll have to
>>>>>>>>>> support for eternity. I fail to see how "System soleInstance" is any
>>>>>>>>>> better
>>>>>>>>>> than "SmalltalImage current".
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why would you write System soleInstance?
>>>>>>>>> You will just write Smalltalk.
>>>>>>>>
>>>>>>>> Oh, I see. Sorry, I misread this, I just saw another cleansing jihad coming
>>>>>>>> that rewrites all references to SmalltalkImage current with System
>>>>>>>> soleInstance :-) Never mind then.
>>>>>>>>
>>>>>>>>> I was speaking of renaming SmalltalkImage (not urgent at all) to
>>>>>>>>> reflect that Smalltalk is the soleInstance of System.
>>>>>>>>> And we don't have to rename soleInstance either, it was just for
>>>>>>>>> explaining the concept.
>>>>>>>>
>>>>>>>> Yes, that's a significant part of my motivation for option #2 as well.
>>>>>>>> Having Smalltalk *be* a SystemDictionary isn't really all that useful I
>>>>>>>> think (although it doesn't really hurt either).
>>>>>>>>
>>>>>>>
>>>>>>> It hurts, because there is no documentation (which is mostly our case
>>>>>>> today), and its easy to shoot yourself in own foot
>>>>>>> like using #removeKey: instead of #removeClass: and things like that.
>>>>>>> Exposing a low-level protocol to the universe is just plain wrong!
>>>>>>> Not for you as an expert, but think about newcomers.
>>>>>>> Instead of telling users 'please don't use this, or you will be
>>>>>>> punished', it is much better to build things in a way,
>>>>>>> which will make them hard to abuse (or even better - there will be no
>>>>>>> need for abuses), but even if its sometimes needed,
>>>>>>> things should be organized in a such way, that there will be clear
>>>>>>> understanding what might happen, when he will bypass a  safeguards,
>>>>>>> because he will learn from a present architecture and so will think
>>>>>>> twice if he doing right thing.
>>>>>>>
>>>>>>> Needless to say, that we should discourage from using globals. That's
>>>>>>> why 'Smalltalk tools browse: #foo' is much better than
>>>>>>> 'ToolSet browse: #foo'. Because its ok, when you have single, well
>>>>>>> known root global, but when you having dozens of them scattered over
>>>>>>> image.. things become worse and worse.
>>>>>>>
>>>>>>
>>>>>> We could ask why memorizing a message name is simpler than memorizing
>>>>>> a global name ?
>>>>>> Well it's not.
>>>>>>
>>>>>> Unless we use poor semantics in class names (Framework Handler System
>>>>>> Management.etc. are not so informative.keywords...).
>>>>>> We feel forced to use such silly names because we are in a global namespace...
>>>>>> For messages, the namespace is a bit more local.
>>>>>>
>>>>>> So why using a message would be better than a global ?
>>>>>> -1) because of the tools: we get a well known entry point for
>>>>>> browsing: Smalltalk
>>>>>> -2) because the message can redirect to any object, eventually conditionnally
>>>>>> -3) it is much easier to refactor code while maintaining
>>>>>> compatibility: just change an implementor instead of many senders
>>>>>> and we need to refactor when introducing new abstractions...
>>>>>>
>>>>> this is also means better modulatiry.
>>>>>
>>>>> -4) Because of the way of thinking. First thought, when you need
>>>>> something to do is: 'I need to find method',
>>>>> not 'I need a SystemNavigation to find a method'. This means, that
>>>>> initially, to describe our intent we using verbs, which characterizing
>>>>> what you going to do,  and only then we going to next question 'what
>>>>> is a proper tool to do that?'  or 'what object(s) should be used to do
>>>>> that?'. And in this way we are forming a message - selector is verb,
>>>>> and receiver is noun.
>>>>
>>>> Well, not exactly here, we are complexifying the grammar a bit:
>>>>
>>>> Smalltalk vm
>>>> Smalltalk commandLine
>>>>
>>>> This are just nouns at genitive case... The verb will follow.
>>>>
>> It was about removing extra globals from use.
>> Smalltalk vm version.  Smalltalk query implementorsOf: #foo
>> is better than
>> SmalltalkVm version. SystemNavigation implementorsOf: #foo
>> because we using less globals :)
>>
>
> 100% agree of course.
> A Smalltalk global is just a static reference to anobject (with early binding).
> A Smalltalk message is a late bound invocation of a program.
>
> Which one is enabling conditional execution, security checkings, lazy
> initialization, module discovery & loading etc... ?
>
> Nicolas
>
>>>> Nicolas
>>>>
>>>
>>> Just another thought: you might ask does it scale ?
>>> No.
>>> Having thousands of message or more indirections would just be bad...
>>>   Smalltalk vm memory policy doSomething
>>>
>> will you prefer 'SmalltalkVMMemoryPolicy doSomething'? ;)
>>
>> The explosion of names have to happen somewhere, when you adding new
>> functionality.
>>
>>> But the answer is:we don't want to scale !
>>> We want a small manageable Kernel, don't we ?
>>>
>>
>> indeed.
>>
>>> Nicolas
>>>
>>>>> And, obviously, because of that, first thing which one going do is to
>>>>> look for implementors of 'find' or 'findMethod', because it is really
>>>>> irrelevant who is implementor, once it satisfies the need. And so, it
>>>>> is not important to have a global with nice name which will reflect
>>>>> what it is used for or its potential behavior
>>>>> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
>>>>> much more important to have a properly named methods which
>>>>> implementing this behaivor.
>>>>>
>>>>>> Maybe some will see other advantages (security ?)
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>>> Hm ... now that I've been thinking about it I'm starting to lean for #2
>>>>>>>> myself a little more.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>  - Andreas
>>>>>>>>
>>>>>>>>>> Seriously, if we want to move this stuff forward we should be starting by
>>>>>>>>>> having a moratorium on adding new methods to the old places and rather
>>>>>>>>>> discuss where *new methods* should live. This way we learn over some
>>>>>>>>>> period
>>>>>>>>>> what works and what doesn't and if we're happy with the outcome then we
>>>>>>>>>> move
>>>>>>>>>> a few more bits to those places. The approach of "let's just fix this
>>>>>>>>>> problem once and forever" simply does not work here because the solution
>>>>>>>>>> space is too big.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Using a message indirection like Smalltalk vm certainly helps.
>>>>>>>>> But sure, it does not solve every problem,
>>>>>>>>> One day or the other, we will want to change the level of abstraction
>>>>>>>>> for sure...
>>>>>>>>>
>>>>>>>>>> Concretely speaking, what would be alternative places for the cleanup
>>>>>>>>>> methods that I just added, and why? Where would you expect them and why?
>>>>>>>>>> If
>>>>>>>>>> we have a good place we might start moving a few of the other
>>>>>>>>>> housekeeping
>>>>>>>>>> methods over there. To me, this is a much more fruitful direction than
>>>>>>>>>> the
>>>>>>>>>> above.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would start with minimal changes and gradually introduce indirection
>>>>>>>>> messages.
>>>>>>>>> Then slowly deprecate message, and provide optional compatibility modules.
>>>>>>>>> But there, I always prefer a deeper analysis on true code :)
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>  - Andreas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Igor Stasenko AKA sig.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>