On Mon, Dec 2, 2013 at 2:11 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 2 December 2013 20:52, Chris Muller <asqueaker@gmail.com> wrote:
> I agree wtih Bert, this is generally useful.  I have demand now.  Maui
> rolls this function for itself but would prefer to have it in the
> image.
>
> It should be on Symbol, not String, because we're talking about method
> selectors, which are always Symbols.

I had debated putting the methods on Symbol, but I had (and still
have) no idea whether or not they would always be Symbols, and not
user input.

I would not oppose moving them to Symbol, and adjusting the tests.

> The proposal to put it in a "utility" class reminds me of an old Java
> gig, where we couldn't extend classes with additional methods.  Proper
> delegation of a needed behavior is not "monkey patching", which
> carries a derogatory connotation.

Yes, which is half of why I use the term :)

More seriously, in Ruby it's considered a bad smell, but in Ruby you
don't interact with a running system. So in Ruby, it's really hard to
find out which packages overwrote each other's patches, whereas the
problem is much easier to debug and to fix in Smalltalk.

It is still a problem in Smalltalk, which is why we have such an
aversion to Monticello overrides. Environments could offer the chance
to _with an Environment_ add methods to classes. But to do that
properly you'd need to change method lookup. I _think_ that means you
end up with Newspeak's "comb" method lookup? Eliot could say for sure.

I'm not sure one needs to change the VM at all.  First, I think one can get a long way with an environment pragma:

    myExtension
        <environment: MyEnvironment>
        ^AGlobalInMyEnvironment

Second, adding symbols that are private to an environment is IMO a much easier way to go than Newspeak's sends.  That's an experiment that would be fun.  The VM makes no assumptions about message selectors; they can be immediates if desired.  So having a structured object that looks like
    ArrayedCollection subclass: #PrivateSelector
                              instanceVariableNames: 'symbol environment'
should be possible.  But this could well be a bigger change than environments itself.  I think it solves a lot of problems, but it's work.
 

frank

> On Mon, Dec 2, 2013 at 4:22 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
>> On 2 December 2013 10:16, Bert Freudenberg <bert@freudenbergs.de> wrote:
>>>
>>> On 2013-11-30, at 01:00, Frank Shearar <frank.shearar@gmail.com> wrote:
>>>
>>>> On 29 November 2013 23:50, tim Rowledge <tim@rowledge.org> wrote:
>>>>>
>>>>> On 29-11-2013, at 3:38 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
>>>>>
>>>>>> On 29 November 2013 21:51, tim Rowledge <tim@rowledge.org> wrote:
>>>>>>>
>>>>>>> On 29-11-2013, at 12:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
>>>>>>>
>>>>>>>> inherentSelectorForGetter
>>>>>>> That’s absolutely a Symbol method and really ought always have been there.
>>>>>>
>>>>>> It wasn't clear to me either from the senders-of or the implementation
>>>>>> whether it should go on Symbol or String, so I went with the
>>>>>> broader/safer option, and put it on String.
>>>>>>
>>>>>> But I take it you're voting for "put it on the dang object" option
>>>>>> rather than "monkey patching is evil”?
>>>>>
>>>>> Guess so; methods ought to go in The Right Place. Now *defining* that place… that’s where the art is.
>>>>
>>>> And so a method that takes a string/symbol and turns it into some
>>>> slightly different symbol pretty much ought to go on String/Symbol.
>>>>
>>>> I'm leaning heavily towards the monkey patch option, and not just
>>>> because I have the work done waiting for committing. I'll hold off on
>>>> anything for the moment though, both because it has a rather large
>>>> number of changes to Etoys and to give others a chance to chime in.
>>>> That it's midnight here, and I'm tired and hence not in the best shape
>>>> to do dangerous things like commit changes has nothing at all to do
>>>> with the waiting. Promise.
>>>>
>>>> frank
>>>
>>> Converting between setters and getters seems generally useful to me, so even if at the moment it may be only used in Etoys, I'd not make it an Etoys-specific extension.
>>
>> Since we ship Etoys in a standard Squeak image, how about we keep
>> these methods in Etoys until we do start mangling selectors elsewhere?
>> In other words, pull the methods out on demand? (I have no objections
>> to them moving out of Etoys if they do prove to be generally useful.)
>>
>> frank
>>
>>> - Bert -
>>>
>>>
>>>
>>
>




--
best,
Eliot