[squeak-dev] Utilities' symbol mangling methods

Eliot Miranda eliot.miranda at gmail.com
Mon Dec 2 23:08:22 UTC 2013


On Mon, Dec 2, 2013 at 2:11 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 2 December 2013 20:52, Chris Muller <asqueaker at 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 at gmail.com>
> wrote:
> >> On 2 December 2013 10:16, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >>>
> >>> On 2013-11-30, at 01:00, Frank Shearar <frank.shearar at gmail.com>
> wrote:
> >>>
> >>>> On 29 November 2013 23:50, tim Rowledge <tim at rowledge.org> wrote:
> >>>>>
> >>>>> On 29-11-2013, at 3:38 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
> >>>>>
> >>>>>> On 29 November 2013 21:51, tim Rowledge <tim at rowledge.org> wrote:
> >>>>>>>
> >>>>>>> On 29-11-2013, at 12:43 PM, Frank Shearar <frank.shearar at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131202/ef7e00fd/attachment.htm


More information about the Squeak-dev mailing list