2009/2/24 Brian Ford <brixen / gmail.com>

> On Feb 24, 3:17 pm, Yehuda Katz <wyc... / gmail.com> wrote:
> > 2009/2/24 Eero Saynatkari <ruby... / kittensoft.org>
> >
> > > Excerpts from brixen's message of Wed Feb 25 00:04:34 +0200 2009:
> > > > In implementing Rubinius, we have only encountered one major issue
> > > > with redefining a core library method: mathn changing Fixnum#/.
> >
> > > In addition to overriding, selectors can be used for adding (and,
> > > if implemented file-/block-wise, deleting.)
> >
> > Frankly, the proposal is completely unrelated to something you would have
> > encountered while implementing Rubinius. By definition, the core classes
> are
> > globally available, and not suitable for selector namespacing.
> >
> > > > At least as important (if not more) as seeing what a language feature
> > > > makes easy is seeing what a language feature makes hard. What will it
> > > > look like in code when folks inevitable try to work around the fences
> > > > you erect with your selector namespaces? They will try to work around
> > > > them.
> >
> > The proposal really does not erect any kind of fences. It establishes
> some
> > core extensions for use only inside of a specific file. Nothing stops
> users
> > from reopening the namespaces (in the proposal, they are simple modules)
> and
> > modifying the methods. Likewise, nothing stops users from using the
> > namespaces in their own code. There is nothing in the proposal designed
> to
> > block users from doing what they want.
> >
> > > > Engineering software by trying to protect against the invisible,
> > > > unknowable, purely speculative demons that lurk in some future world
> > > > leads to horrible languages and even worse software. One of the
> things
> > > > Ruby has going for it is some very good software that judiciously
> > > > changes assumptions made at the time other software/code was written.
> >
> > The proposal is based on real-life problems faced by real-life users
> using
> > real-life frameworks. I captured the use-case in the OP (Rails and Merb
> both
> > defining String#camel_case), which has actually bitten real users trying
> to
> > use Merb with ActiveRecord.
>
> You have misunderstood my point. I'm not saying you don't have a
> problem. I'm saying selector namespaces will be used in the way I
> indicated.


What way is that exactly?


> And it will lead to ugly, more confusing software. You can
> solve your problem without selector namespaces. Instead of focusing on
> why you think they are a good idea, I suggest considering how they can
> be misused.
>
> All you are saying is you want a way to define methods on the same
> class with the same name but different behaviors, where the particular
> method called is selected by context. I get it. I think it's a bad
> idea.
>
> Brian
>
> >
> >
> >
> > > I think the two paragraphs contrast a bit :)
> >
> > > However, to offer an alternative consideration, how about a real
> > > mechanism for "unrequiring" and/or "unextending"? Particularly the
> > > non-methodwise variants of selector namespaces could very well be
> > > replaced by being able to (really) activate and deactivate files
> > > or modules at runtime.
> >
> > unrequiring is actually more complex of a feature to implement with no
> > additional benefits that I can see. unextending doesn't solve the problem
> at
> > all (except to provide a slow and extremely awkward way to emulate the
> > feature on an object-by-object basis).
> >
> > The proposal is actually fairly straight-forward, relatively simple to
> > implement, and does not introduce any "barriers" for users at all.
> >
> > --
> >
> > > Magic is insufficiently advanced technology.
> >
> > --
> > Yehuda Katz
> > Developer | Engine Yard
> > (ph) 718.877.1325
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325