[Nitro] A better #is ?

Trans 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:
> Hi,
> > However, that sort of misleads the programmer. #include is not
> > actually happening at all.
> well, same here,
> class MyClass
>    is MyModule
> end
> 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 mailing list