<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 2:11 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2 December 2013 20:52, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
> I agree wtih Bert, this is generally useful. I have demand now. Maui<br>
> rolls this function for itself but would prefer to have it in the<br>
> image.<br>
><br>
> It should be on Symbol, not String, because we're talking about method<br>
> selectors, which are always Symbols.<br>
<br>
I had debated putting the methods on Symbol, but I had (and still<br>
have) no idea whether or not they would always be Symbols, and not<br>
user input.<br>
<br>
I would not oppose moving them to Symbol, and adjusting the tests.<br>
<br>
> The proposal to put it in a "utility" class reminds me of an old Java<br>
> gig, where we couldn't extend classes with additional methods. Proper<br>
> delegation of a needed behavior is not "monkey patching", which<br>
> carries a derogatory connotation.<br>
<br>
Yes, which is half of why I use the term :)<br>
<br>
More seriously, in Ruby it's considered a bad smell, but in Ruby you<br>
don't interact with a running system. So in Ruby, it's really hard to<br>
find out which packages overwrote each other's patches, whereas the<br>
problem is much easier to debug and to fix in Smalltalk.<br>
<br>
It is still a problem in Smalltalk, which is why we have such an<br>
aversion to Monticello overrides. Environments could offer the chance<br>
to _with an Environment_ add methods to classes. But to do that<br>
properly you'd need to change method lookup. I _think_ that means you<br>
end up with Newspeak's "comb" method lookup? Eliot could say for sure.<br></blockquote><div><br></div><div>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:</div>
<div><br></div><div> myExtension</div><div> <environment: MyEnvironment></div><div> ^AGlobalInMyEnvironment</div><div><br></div><div>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</div>
<div> ArrayedCollection subclass: #PrivateSelector</div><div> instanceVariableNames: 'symbol environment'</div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
frank<br>
<br>
> On Mon, Dec 2, 2013 at 4:22 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>> On 2 December 2013 10:16, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>>><br>
>>> On 2013-11-30, at 01:00, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>>><br>
>>>> On 29 November 2013 23:50, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
>>>>><br>
>>>>> On 29-11-2013, at 3:38 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>>> On 29 November 2013 21:51, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
>>>>>>><br>
>>>>>>> On 29-11-2013, at 12:43 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>>> inherentSelectorForGetter<br>
>>>>>>> That’s absolutely a Symbol method and really ought always have been there.<br>
>>>>>><br>
>>>>>> It wasn't clear to me either from the senders-of or the implementation<br>
>>>>>> whether it should go on Symbol or String, so I went with the<br>
>>>>>> broader/safer option, and put it on String.<br>
>>>>>><br>
>>>>>> But I take it you're voting for "put it on the dang object" option<br>
>>>>>> rather than "monkey patching is evil”?<br>
>>>>><br>
>>>>> Guess so; methods ought to go in The Right Place. Now *defining* that place… that’s where the art is.<br>
>>>><br>
>>>> And so a method that takes a string/symbol and turns it into some<br>
>>>> slightly different symbol pretty much ought to go on String/Symbol.<br>
>>>><br>
>>>> I'm leaning heavily towards the monkey patch option, and not just<br>
>>>> because I have the work done waiting for committing. I'll hold off on<br>
>>>> anything for the moment though, both because it has a rather large<br>
>>>> number of changes to Etoys and to give others a chance to chime in.<br>
>>>> That it's midnight here, and I'm tired and hence not in the best shape<br>
>>>> to do dangerous things like commit changes has nothing at all to do<br>
>>>> with the waiting. Promise.<br>
>>>><br>
>>>> frank<br>
>>><br>
>>> 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.<br>
>><br>
>> Since we ship Etoys in a standard Squeak image, how about we keep<br>
>> these methods in Etoys until we do start mangling selectors elsewhere?<br>
>> In other words, pull the methods out on demand? (I have no objections<br>
>> to them moving out of Etoys if they do prove to be generally useful.)<br>
>><br>
>> frank<br>
>><br>
>>> - Bert -<br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>