On Jul 23, 2009, at 12:20 AM, Hans Dieter Pearcey wrote:

On Thu, Jul 23, 2009 at 12:07:22AM -0400, Stevan Little wrote:
Yes, well but it also has arrays, hashes, etc etc etc. I guess what I am thinking is (as Chris says in his response to you) a package is just a "non-anonymous namespace stash", where a Module could be more then that (I have many times pondered adding my favorite ML style module stuff to
it actually).

I guess this depends on how far we want to take CMOP from what's actually
present in Perl.

Yeah, this is a constant struggle in my head.

'Module', in particular, is kind of an overused term here, since it means roughly "package in a file whose name matches the package's when put through a
certain transformation".

On the other hand, Sub::Exporter (which I assume a notional pumped- up Module would use or be based on) promotes a similar view of an exporting module's subs as more than just "bits in a namespace that get stuck over there sometimes",
with its support for inherited exports and so on.

CMOP also goes farther than what's strictly in Perl with Attribute, for
whatever that's worth.

Sorry for being so wishy-washy, but I don't really know what I think is best. Convince me! (In particular, go into more detail on your "favorite ML style
module stuff".)


So, if we were to go more with the Ruby model of Module then actually this is not that far off. Ruby modules are the entire basis of their mixins system (which we all know is the poor mans roles). So adding method-ish type stuff to Module has some precedent.

As for the ML-type stuff. It is nothing more then language fetishism it has little value in reality since Perl will never type check a module. However this does relate somewhat to my Role Functor idea that I blabed about on my blog recently.

- Stevan

Reply via email to