[Nitro] A better #is ?
transfire at gmail.com
Fri Jul 27 13:18:25 EDT 2007
On Jul 27, 9:55 am, "Jonathan Buch" <j... at oxyliquit.de> wrote:
> > However, that sort of misleads the programmer. #include is not
> > actually happening at all.
> well, same here,
> class MyClass
> is MyModule
> I have absolutely no idea what is going on here, without first reading
> the code (or documentation for that matter), if it does include, or
> extend or does something completely different.
> Now, that isn't necessarily a bad thing, all the end user will only ever
> do `is FooBlah` and will happily use the facilities it provides.
> What I'm not sure is if we need that kind of power in the backend,
> do you have any 'bigger usecase' in mind?
Well, the bigger picture that I see is due to the annoyance of the
smaller ones. I really hate having to know if a given module is
intended to be included or extended in order to give me the desired
functionality. I have to look it up! Take Forwardable for example. Do
you know how to use it? So to me, #is is actually better. I don't care
how is does what it does, just that it does it. If I need to care how,
then I can resort to include and extend. So that's the first thing.
Then there is ClassMethods/class_extension. I'm still not happy with
these, and I continue to seek a remedy. As of late I've decided that
the best course (short of a core-change) is a 3rd method beside
include and extend that would notice a ClassMethods section and act
accordingly. But that's actually beside the point. If we decide #is
should have this more versatile use, then it's easy enough to add this
third possibly to the mix.
I guess ultimately I'm asking to what extent do we prefer the
simplicity if is => include, vs the convenience a smart #is can bring
to the table.
More information about the Nitro-general