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