Excerpts from Goro Fuji's message of Wed Aug 12 19:57:56 -0700 2009:
After considering this issue, I concluded that method_map related
stuff are not suitable to Package. Module may be a better place, so I
made a branch, topic/method_map-to-module. How about this?
After considering this issue, I concluded that method_map related
stuff are not suitable to Package. Module may be a better place, so I
made a branch, topic/method_map-to-module. How about this?
http://github.com/nothingmuch/class-mop/tree/topic/method_map-to-module
--
Goro Fuji (gfx)
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
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
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
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
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
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
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.
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
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
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) = @_;
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 =
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
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
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
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
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
18 matches
Mail list logo
