Ovid wrote:
The "intermediate class" solves the problem but it instantly suggests
that we have a new "design pattern" we have to remember. Basically, if
I can't lexically scope the additional behavior a role offers, I
potentially need to remove the role or use the "intermediate class"
pattern.
On Thu, Oct 12, 2006 at 09:27:53AM -0700, Jonathan Lang wrote:
: To modify a class at runtime, use C.
C is compile time. You'd have to eval it.
Larry
Miroslav Silovic wrote:
Paul Seamons wrote:
>
> On closer inspection, is it even possible to add a Role to a Class at
> runtime?
>
If it isn't now, I would certainly like to have a hook available through
MOP (which is, to the best of my knowledge, still unspecified).
To modify a class at runti
Paul Seamons wrote:
On closer inspection, is it even possible to add a Role to a Class at
runtime?
If it isn't now, I would certainly like to have a hook available through
MOP (which is, to the best of my knowledge, still unspecified).
I thought that Class and Role composition outside
在 Oct 12, 2006 2:39 PM 時，Ovid 寫到：
--To forcefully add a role to a class at a distance during runtime,
use
a class object call (see Moose::Meta::Class for more about these
APIs):
^Dog.add_role(^Catlike);
That's more of what I was thinking, but where is this documented? I
can't find
--- Audrey Tang <[EMAIL PROTECTED]> wrote:
> > I always thought when a role is applied to a class at runtime you
> > get a new (anonymous) subclass. The original class isn't affected.
>
> Right, that's what usually happens with:
>
> my Dog $fido .= new;
> $fido does Catlike;
Am I miss
在 Oct 12, 2006 5:43 AM 時，Tim Bunce 寫到：
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote:
Hi all,
In doing a bit of work with traits (roles) in Perl 5
(http://perlmonks.org/?node_id=577477), I've realized some edge cases
which could be problematic.
First, when a role is applied to a class
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote:
> Hi all,
>
> In doing a bit of work with traits (roles) in Perl 5
> (http://perlmonks.org/?node_id=577477), I've realized some edge cases
> which could be problematic.
>
> First, when a role is applied to a class at runtime, a instance of tha
--- TSa <[EMAIL PROTECTED]> wrote:
> > First, when a role is applied to a class at runtime, a instance of
> > that class in another scope may specifically *not* want that role.
> > Is there a way of restricting a role to a particular lexical scope
> > short of applying that role to instances instea
> First, when a role is applied to a class at runtime, a instance of that
> class in another scope may specifically *not* want that role. Is there a
> way of restricting a role to a particular lexical scope short of applying
> that role to instances instead of classes?
Seems like you could use an
HaloO,
Ovid wrote:
First, when a role is applied to a class at runtime, a instance of
that class in another scope may specifically *not* want that role.
Is there a way of restricting a role to a particular lexical scope
short of applying that role to instances instead of classes?
I think you'l
HaloO,
Ovid wrote:
Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says:
You can also mixin a precomposed set of roles:
$fido does Sentry | Tricks | TailChasing | Scratch;
Should that be the following?
$fido does Sentry & Tricks & TailChasing & Scratch;
If you follow my
Hi all,
I posted this to Perl6 users, but I was Warnocked, it was the wrong list, or
both. Here's another stab at it.
In doing a bit of work with traits (roles) in Perl 5
(http://perlmonks.org/?node_id=577477), I've realized some edge cases which
could be problematic.
First, when a role is a
Hi all,
In doing a bit of work with traits (roles) in Perl 5
(http://perlmonks.org/?node_id=577477), I've realized some edge cases
which could be problematic.
First, when a role is applied to a class at runtime, a instance of that
class in another scope may specifically *not* want that role. Is
14 matches
Mail list logo
