CMOP::Class / CMOP::Package
I just merged the method_map_move branch into master; this takes all of the methods that operate only on the current class's methods and moves them into CMOP::Package (get_method, has_method, etc.). CMOP::Class still has everything to do with introspection of (possibly) inherited methods. This clears the way for refactoring some duplicated code between CMOP::Class and Moose::Meta::Role. hdp.
Re: CMOP::Class / CMOP::Package
My only issue with this is that methods are not really parts of packages, methods are class things. Perhaps we could call it code_ref_map or something better so we can get the actual functionality, and then Role and Class can just alias them to method_mao or something like that? And perhaps this is something we could put in C::MOP::Module, since Package is meant to model Perl 5 packages and Module is sort of an in- between thing that comes from Perl 6 but is not terrible well defined. Dunno, just some random thoughts. - Stevan On Jul 22, 2009, at 7:17 PM, Hans Dieter Pearcey wrote: I just merged the method_map_move branch into master; this takes all of the methods that operate only on the current class's methods and moves them into CMOP::Package (get_method, has_method, etc.). CMOP::Class still has everything to do with introspection of (possibly) inherited methods. This clears the way for refactoring some duplicated code between CMOP::Class and Moose::Meta::Role. hdp.
Re: CMOP::Class / CMOP::Package
On Wed, 22 Jul 2009, Stevan Little wrote: My only issue with this is that methods are not really parts of packages, methods are class things. Perhaps we could call it code_ref_map or something better so we can get the actual functionality, and then Role and Class can just alias them to method_mao or something like that? Can we call it subroutine_map, not code_ref_map? And perhaps this is something we could put in C::MOP::Module, since Package is meant to model Perl 5 packages and Module is sort of an in-between thing that comes from Perl 6 but is not terrible well defined. According to the docs, a module is essentially a Class::MOP::Package with metadata, in our case the version and authority. So it seems to me that a Package can have subroutines. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: CMOP::Class / CMOP::Package
On Wed, Jul 22, 2009 at 11:22 PM, Dave Rolskyauta...@urth.org wrote: On Wed, 22 Jul 2009, Stevan Little wrote: And perhaps this is something we could put in C::MOP::Module, since Package is meant to model Perl 5 packages and Module is sort of an in-between thing that comes from Perl 6 but is not terrible well defined. According to the docs, a module is essentially a Class::MOP::Package with metadata, in our case the version and authority. So it seems to me that a Package can have subroutines. In fact I believe that in Perl5 Packages are just a fancy way of saying non-anonymous namespace stash which if I recall contain Code Refs. -Chris
Re: CMOP::Class / CMOP::Package
On Wed, Jul 22, 2009 at 08:54:08PM -0400, Stevan Little wrote: My only issue with this is that methods are not really parts of packages, methods are class things. Perhaps we could call it code_ref_map or something better so we can get the actual functionality, and then Role and Class can just alias them to method_mao or something like that? The only reason I didn't do this is because every consumer of this API (CMOP::Class, Moose::Role) cares about methods, not 'subroutines', so it seemed like drawing a distinction that, while valid, would be currently useless. If the plan is for CMOP::Package to grow more extensive exporting/inclusion functionality, I could see more value. It still may make sense for an intermediate module that is a package containing subs intended to be called as methods, but I have no idea what that would be called. hdp.
Re: CMOP::Class / CMOP::Package
On Jul 23, 2009, at 12:03 AM, Hans Dieter Pearcey wrote: On Wed, Jul 22, 2009 at 08:54:08PM -0400, Stevan Little wrote: My only issue with this is that methods are not really parts of packages, methods are class things. Perhaps we could call it code_ref_map or something better so we can get the actual functionality, and then Role and Class can just alias them to method_mao or something like that? The only reason I didn't do this is because every consumer of this API (CMOP::Class, Moose::Role) cares about methods, not 'subroutines', so it seemed like drawing a distinction that, while valid, would be currently useless. If the plan is for CMOP::Package to grow more extensive exporting/ inclusion functionality, I could see more value. It still may make sense for an intermediate module that is a package containing subs intended to be called as methods, but I have no idea what that would be called. Module, it is already there a Module isa Package and a Class isa Module. - Stevan
Re: CMOP::Class / CMOP::Package
On Thu, Jul 23, 2009 at 12:08:14AM -0400, Stevan Little wrote: Module, it is already there a Module isa Package and a Class isa Module. I know Module is there, but there's nothing in the current concept of a Perl module that implies it is only for methods (vs. functions). hdp.
Re: CMOP::Class / CMOP::Package
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. '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.) hdp.
Re: CMOP::Class / CMOP::Package
On Thu, Jul 23, 2009 at 12:12 AM, Hans Dieter Pearceyh...@pobox.com wrote: On Thu, Jul 23, 2009 at 12:08:14AM -0400, Stevan Little wrote: Module, it is already there a Module isa Package and a Class isa Module. I know Module is there, but there's nothing in the current concept of a Perl module that implies it is only for methods (vs. functions). Honestly I think the term for what you're looking for is Class in most places ... but most places don't have Roles and complex metaframeworks. I propose we call them Alberts on the basis that I like the name and it's equally as silly as any other name I could come up with. -Chris
Re: CMOP::Class / CMOP::Package
On Thu, Jul 23, 2009 at 12:21 AM, Goro Fujig.psy...@gmail.com wrote:
Hi,
I wonder why Role inherits methods from Class.
Even if a role is not a Class, we can override the can() method.
package Moose::Meta::Role;
our @ISA = qw(Class::MOP::Class);
sub isa{
my($self, $class) = @_;
return $self-SUPER::isa($class) (ref $self || $self) ne
'Class::MOP::Class';
}
Now Role acts as Class, but not is-a Class.
--
Goro Fuji (gfx)
Bleh.
This is distasteful if for no other reason than it goes against the
very thing I've been arguing about with regards to Roles for Behavior
and Classes for Taxonomy. True we don't have Traits in CMOP (yet) and
we don't use them in Moose (yet) ... but the plan is eventually we
will and this kind of inheritance-for-code-reuse thing will only need
to be revisited then. We already have a common set of package that
both Moose::Meta::Class and Moose::Meta::Role inherit from ... we're
just bike-shedding over how far up the tree to put the common
behavior.
-Chris
Re: CMOP::Class / CMOP::Package
On Thu, Jul 23, 2009 at 01:21:18PM +0900, Goro Fuji wrote:
I wonder why Role inherits methods from Class.
Do you mean doesn't inherit? Right now they're basically duplicated.
Even if a role is not a Class, we can override the can() method.
package Moose::Meta::Role;
our @ISA = qw(Class::MOP::Class);
sub isa{
my($self, $class) = @_;
return $self-SUPER::isa($class) (ref $self || $self) ne
'Class::MOP::Class';
}
Now Role acts as Class, but not is-a Class.
Ugh. I'd rather have something like the immutable trait than fiddle with isa.
Or use inheritance in a more straightforward way, with a single package they
both inherit from (which is where this discussion started, after all).
hdp.
Re: CMOP::Class / CMOP::Package
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
Re: CMOP::Class / CMOP::Package
On Thu, Jul 23, 2009 at 12:32:12AM -0400, Stevan Little wrote: 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. Ruby's Module is the cop-out reason I gave myself for continuing to call it 'method' when I moved it. I'm not sure Ruby is a good enough authority to appeal to, though, unlike CLOS or Smalltalk or something. hdp.
Re: CMOP::Class / CMOP::Package
Goro,
But the problem is that Class also has the notion of inheritance,
which Roles do not.
This is the closest I have come to a Class/Role model, but i never
figured out how to implement it cleanly.
http://img.skitch.com/20090723-qjrrm9m52uj5919nn67wj7ddrr.jpg
Class is an instance of Class (we already have this)
Role is an instance of Class
Role does Role
Class does Role
- Stevan
On Jul 23, 2009, at 12:21 AM, Goro Fuji wrote:
Hi,
I wonder why Role inherits methods from Class.
Even if a role is not a Class, we can override the can() method.
package Moose::Meta::Role;
our @ISA = qw(Class::MOP::Class);
sub isa{
my($self, $class) = @_;
return $self-SUPER::isa($class) (ref $self || $self) ne
'Class::MOP::Class';
}
Now Role acts as Class, but not is-a Class.
--
Goro Fuji (gfx)
Re: CMOP::Class / CMOP::Package
On Jul 23, 2009, at 12:37 AM, Hans Dieter Pearcey wrote: On Thu, Jul 23, 2009 at 12:32:12AM -0400, Stevan Little wrote: 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. Ruby's Module is the cop-out reason I gave myself for continuing to call it 'method' when I moved it. I'm not sure Ruby is a good enough authority to appeal to, though, unlike CLOS or Smalltalk or something. But it will give us more sex-appeal and make us blog better. - Stevan
Re: CMOP::Class / CMOP::Package
Dave Rolsky wrote: On Wed, 22 Jul 2009, Stevan Little wrote: My only issue with this is that methods are not really parts of packages, methods are class things. Perhaps we could call it code_ref_map or something better so we can get the actual functionality, and then Role and Class can just alias them to method_mao or something like that? Can we call it subroutine_map, not code_ref_map? And perhaps this is something we could put in C::MOP::Module, since Package is meant to model Perl 5 packages and Module is sort of an in-between thing that comes from Perl 6 but is not terrible well defined. According to the docs, a module is essentially a Class::MOP::Package with metadata, in our case the version and authority. So it seems to me that a Package can have subroutines. If one is looking for a generic term that covers methods and subroutines, either functional or imperative, I would think that routine works best, and yet it is specific enough to exclude a block etc. -- Darren Duncan
