Utilities has #inherentSelectorForGetter:, #setterSelectorFor: and #getterSelectorFor: Etoys makes extensive use of these. MorphicExtras-Flaps also uses Utilities class >> #simpleSetterFor:
I want to remove these from Utilities. The first way to do this that I thought of was to push these messages to String or Symbol, so you could say 'foo' asSetterSelector. That looks quite neat in the code affected by the change. (You also lose a pair of ()s in a lot of places.)
But it occurred to me after I did all this that I could also avoid the monkey patching by adding, say, a class EtoysSymbolExtensions, to house the methods. You'd change the "Utilities getterSelectorFor: thing" to "EtoysSymbolExtensions getterSelectorFor: thing".
Thoughts? Which would be better/nicer? The former makes for better looking code, while the latter avoids monkey patching.
frank
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.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- In serious need of attitude adjustment.
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"?
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- In serious need of attitude adjustment.
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.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BIB: Branch If Branch if branch...
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
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BIB: Branch If Branch if branch...
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.
- Bert -
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 -
On 2013-12-02, at 11:22, Frank Shearar frank.shearar@gmail.com wrote:
On 2 December 2013 10:16, Bert Freudenberg bert@freudenbergs.de wrote:
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
I'm fine either way. However, it seems to me a third-party package would rather roll their own than depending on Etoys-stuff, no? Depending on System is fine, as is (even more so) on Collections, but depending on Etoys, not so much.
- Bert -
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.
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.
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 -
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.
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 -
On Mon, Dec 2, 2013 at 2:11 PM, Frank Shearar frank.shearar@gmail.comwrote:
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 -
Hi Chris,
On Mon, 2 Dec 2013 14:52:59 -0600, Chris Muller asqueaker@gmail.com wrote:
It should be on Symbol, not String, because we're talking about method selectors, which are always Symbols.
I'm more familiar with VA Smalltalk than Squeak but I think Symbol is a sub class of String in both. As such the method should be on String so it would work when sent to a String or a Symbol as Frank's example "'foo' asSetterSelector" requires.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Yeah, on String is fine.
On Mon, Dec 2, 2013 at 4:11 PM, Louis LaBrunda Lou@keystone-software.com wrote:
Hi Chris,
On Mon, 2 Dec 2013 14:52:59 -0600, Chris Muller asqueaker@gmail.com wrote:
It should be on Symbol, not String, because we're talking about method selectors, which are always Symbols.
I'm more familiar with VA Smalltalk than Squeak but I think Symbol is a sub class of String in both. As such the method should be on String so it would work when sent to a String or a Symbol as Frank's example "'foo' asSetterSelector" requires.
Lou
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
On 02-12-2013, at 2:11 PM, Louis LaBrunda Lou@Keystone-Software.com wrote:
Hi Chris,
On Mon, 2 Dec 2013 14:52:59 -0600, Chris Muller asqueaker@gmail.com wrote:
It should be on Symbol, not String, because we're talking about method selectors, which are always Symbols.
I'm more familiar with VA Smalltalk than Squeak but I think Symbol is a sub class of String in both. As such the method should be on String so it would work when sent to a String or a Symbol as Frank's example "'foo' asSetterSelector" requires.
Yup; I’d stick it to String simply because a surprisingly large number of people do things like (#globble, ‘Wibbet’, self thingyString) asSymbol and involve Strings as well as Symbols in arcane nekomancy (that’s magic based on a cute cat running around a screen).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: EF: Emulate Fireworks
On 3 December 2013 00:51, tim Rowledge tim@rowledge.org wrote:
arcane nekomancy (that’s magic based on a cute cat running around a screen).
That's one of the funniest things I've read in a long time!
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: EF: Emulate Fireworks
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Eliot Miranda -
Frank Shearar -
Louis LaBrunda -
tim Rowledge