From: Alder Green <alder.green@...>
Date: 2006-06-10T06:17:52+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?

On 6/9/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

> I'm still leaning towards having just one method, include, that is
> available to client classes to "use" the module in typical cases. The
> module decides what gets included at the instance and class levels.

The major lack right now is a way to "include" module methods. Even if
the module is to be the one deciding which methods get exported, it
does not have a straightforward way to export its own self-methods.
The lack of such a way right now forces us to various underhanded
hacks, e.g. to first ill-define those module-methods as instance
methods, and then use #extend in various unnatural ways, ending up
with a lot of boilerplate code and duplicated, redundant instance
methods no-one is ever going to use directly (the ugly ClassMethods
module with all its krufty instance-methods would remain in the
namespace).

> The #imported callback might help (and it would inevitably be requested
> if it were not provided), but then the module author has to decide how
> to handle each of #included, #imported, and #extended.

I agree, the need to handle 3 cases is somewhat icky. It's also icky
right now with both #included and #extended to block.

I'm not sure how prevalent is the need to limit the ways functionality
in a module can be exported. I never had it, and most of the responses
in the thread are about the opposite need (which I did share several
times) - to allow functionality in the module to propagate more
freely.

So I hope we're not providing here for some hypothetical need absent
from reality. Also, arguably, if you're doing something unnatural like
limiting access to your module's functionality, you should be the one
bothering to secure all hatches (not that it would actually prevent
anyone from hacking it out quite easily... what you're talking about
is more like a warning-system really, a sort of recommendation).

I suspect it should also be possible to easily define macro methods
for auto-generating #included, #imported, and #extended. Which is
better than the state for #import, whose lack cannot be filled by
macros alone, and requires copy-pasting code chunks to each module,
and/or unnatural changes to the way those modules are defined.

> --
>       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>


-- 
-Alder