Re: Runtime role issues

[Aaron Sherman]

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.


my Dog $dog .= new;
my $junkyard = $dog but Guard;

You probably don't need to touch the class, but a particular object. You 
can lexically scope changes to an object using but and my quite easily. 
If you really need a modified class, then I think this would do it, but 
I'm not sure if it works:


my $junkyarddog = class is Dog does Guard {};
my ::($junkyarddog) $spot .= new;

Re: Runtime role issues

[Larry Wall]

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

Re: Runtime role issues

[Jonathan Lang]

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 runtime, use C.


>
> I thought that Class and Role composition outside of compile time
> resulted in
> a new pseudo Class for the subsequent instances of that composition - in
> which case the original Class would remain unmodified.
>

I believe 'does' and 'but' operators work that way, yep. Additionally,
they're per instance. Offhand I don't even recall any way to create an
uninstantiated class with a role mixed at runtime (would my
$class_foobar = ::Foo but ::Bar do the trick?)


Probably not; but C might.

--
Jonathan "Dataweaver" Lang

Re: Runtime role issues

[Miroslav Silovic]

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 of compile time 
resulted in

a new pseudo Class for the subsequent instances of that composition - in
which case the original Class would remain unmodified.



I believe 'does' and 'but' operators work that way, yep. Additionally, 
they're per instance. Offhand I don't even recall any way to create an 
uninstantiated class with a role mixed at runtime (would my 
$class_foobar = ::Foo but ::Bar do the trick?)


  Miro

Re: Runtime Role Issues

[Audrey Tang]

在 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 it in http://dev.perl.org/perl6/doc/design/syn/S12.html.  I
see it in the Moose docs, but is this in Perl 6?  I thought it was.


Well, it's in Perl 6, and Moose is currently the metaobject layer  
when the

VM that runs Perl 6 happens to be perl5...

Right after the 6.2.13 release (which is ready now, except for  
changelogging),
we'll switch to the Moose team's MO system, ensuring that the  
introspectio

APIs work exactly the same way on both GHC and perl5 virtual machines.

Thanks,
Audrey

Re: Runtime Role Issues

[Ovid]

--- 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 missing something here?  That's applying a role to an instance of
a class, not the class itself, and thus *should* create a new anonymous
class.
 
> 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 it in http://dev.perl.org/perl6/doc/design/syn/S12.html.  I
see it in the Moose docs, but is this in Perl 6?  I thought it was.

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Runtime Role Issues

[Audrey Tang]

在 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 at runtime, a instance of  
that

class in another scope may specifically *not* want that role.


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;

Here $fido's class become a new (memoized, anonymous) class that  
still has
"Dog" as its name, but is no longer equivalent to the vanilla ^Dog  
class object.


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);

Thanks,
Audrey

Re: Runtime Role Issues

[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 at runtime, a instance of that
> class in another scope may specifically *not* want that role.

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.

Tim.

> Is there
> a way of restricting a role to a particular lexical scope short of
> merely applying that role to instances instead of classes?
> 
> Second, how can I remove roles from classes?  I've create some code
> which adds an "is_selected" method to some classes but when I'm done,
> I'd like top easily remove that role.  How do I do that?  Seems closely
> related to my first question, but it's still a distinct issue, I think.
> 
> 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;
> 
> Cheers,
> Ovid
> 
> --
> 
> Buy the book -- http://www.oreilly.com/catalog/perlhks/
> Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Runtime role issues

[Ovid]

--- 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 instead of classes?
> 
> I think you'll need an intermediate class that you use to apply your
> role. Classes are open and that implies the possibility to merge
> further roles into them. But this applies for all users of the class.
> How this works when there are already instances I don't know.

Ah, that makes sense.
 
> > Second, how can I remove roles from classes?
> 
> Is that a wise thing to do? Roles are not assigned and removed
> as a regular operation. What is your use case?

I don't think I have a clear use case here because the examples that
come to mind all involve adding and then quickly removing the extra
behaviors when I'm done with them.  That's going to be fraught with
bugs.

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.

I suppose one could look at this as "separation of concerns".  If I
have an MVC framework, instances of objects in the M, V, or C portions
might want to exhibit different behaviors, depending upon what I'm
doing with them, but I don't necessarily want those behaviors to bleed
over to the other layers of my application.  Whether or not this is a
clean way of looking at the problem, I don't know.

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Runtime role issues

[Paul Seamons]

> 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 empty intermediate role to accomplish the same 
thing while leaving the shared class alone.

Shared Class A
Mixin Role B

Class C isa A does B
Class D isa A

Shared Class A is unmodified.

Otherwise, I think that any runtime modification of a class should affect all 
instances and future instances of that class.

On closer inspection, is it even possible to add a Role to a Class at runtime?  
 
I thought that Class and Role composition outside of compile time resulted in 
a new pseudo Class for the subsequent instances of that composition - in 
which case the original Class would remain unmodified.

Paul

Re: Runtime role issues

[TSa]

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'll need an intermediate class that you use to apply your
role. Classes are open and that implies the possibility to merge
further roles into them. But this applies for all users of the class.
How this works when there are already instances I don't know.



Second, how can I remove roles from classes?


Is that a wise thing to do? Roles are not assigned and removed
as a regular operation. What is your use case?


Regards, TSa.
--

Re: Runtime role issues

[TSa]

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 idea of a type lattice build from roles with | as join
and & as meet operator these two mean something completely different.
The first is the join or union of the roles while the second is their
meet or intersection. The first creates a subtype of the roles the
second a supertype. But the typishness of roles is debated.

Regards, TSa.
--

Runtime role issues

[Ovid]

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 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?

Second, how can I remove roles from classes?  I've create some code which adds 
an "is_selected" method to some classes but when I'm done, I'd like top easily 
remove that role.  How do I do that?  Seems closely related to my first 
question, but it's still a distinct issue, I think.

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;

Cheers,
Ovid 
-- 
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Runtime Role Issues

[Ovid]

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 there
a way of restricting a role to a particular lexical scope short of
merely applying that role to instances instead of classes?

Second, how can I remove roles from classes?  I've create some code
which adds an "is_selected" method to some classes but when I'm done,
I'd like top easily remove that role.  How do I do that?  Seems closely
related to my first question, but it's still a distinct issue, I think.

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;

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/