--- On Thu, 1/15/09, Howe, Tom (IT) <tom.h...@morganstanley.com> wrote:
> From: Howe, Tom (IT) <tom.h...@morganstanley.com>
> Subject: RE: Possible to use coerce and auto_deref?
> To: jjn1...@yahoo.com
> Date: Thursday, January 15, 2009, 9:29 AM
> unfortunately auto_deref wont work on a custom type, it
> needs to be ArrayRef[..]
Hmm, I would think this should work, given that the source code checks
'is_a_type_of' not that actual type name. If that doesn't work for you, I
would write a test case to prove it and submit it.
--john
>
> I'm using Types to manage them which is handy but does
> cause some cyclical issues.
>
> I seem to have got around it for now - It seems that it
> makes a big difference where you put your 'use's.
>
>
>
>
>
>
> > -----Original Message-----
> > From: John Napiorkowski [mailto:jjn1...@yahoo.com]
> > Sent: 15 January 2009 14:22
> > To: Howe, Tom (IT)
> > Subject: Re: Possible to use coerce and auto_deref?
> >
> >
> >
> >
> > --- On Wed, 1/14/09, Howe, Tom (IT)
> > <tom.h...@morganstanley.com> wrote:
> >
> > > From: Howe, Tom (IT)
> <tom.h...@morganstanley.com>
> > > Subject: Possible to use coerce and auto_deref?
> > > To: "Sartak" <sar...@gmail.com>
> > > Cc: ch...@prather.org, "Yuval Kogman"
> <nothingm...@woobling.org>,
> > > "Stevan Little"
> <stevan.lit...@iinteractive.com>, moose@perl.org
> > > Date: Wednesday, January 14, 2009, 1:06 PM I have
> something
> > like this:
> > >
> > > subtype 'Thing'
> > > => as 'Object'
> > > => where { $_->isa('ThingClass')
> };
> > >
> > > coerce 'Thing'
> > > => from 'Str'
> > > => via { ThingClass->new ( xyz=> $_ )
> };
> > >
> > >
> > > has 'things' => (
> > > is=>'rw',
> > > isa=>'ArrayRef[Thing]',
> > > lazy=>1,
> > > coerce=>1,
> > > auto_deref=>1,
> > > default => sub { [] },
> > > };
> >
> > Try,
> >
> > subtype 'Thing'
> > => as 'Object'
> > => where { $_->isa('ThingClass') };
> >
> > coerce 'Thing'
> > => from 'Str'
> > => via { ThingClass->new ( xyz=> $_ ) };
> >
> > subtype 'ThingList',
> > as 'ArrayRef[Thing]'
> >
> > coerce 'ThingList',
> > from 'ArrayRef[Str]',
> > via {
> > [ThingClass->new(xyz=>$_) for @$_];
> > };
> >
> > Right now 'deep' coercions, that is coercions
> that coerce
> > elements inside parameterized and structured types,
> are not
> > automatically applied. There's been lengthy
> discussion about
> > this and although at first blush seems useful you
> quickly get
> > into crazy edge cases.
> >
> > So for now if you want them, you'll need to do the
> extra
> > lifting. Consider something like MooseX::Types or at
> least
> > put your types and coercions into a separate library,
> that
> > will help you organize and reuse.
> >
> > John
> >
> > >
> > >
> > > But if I pass in a list of strings to convert to
> Things, I get the
> > > error:
> > >
> > > "Cannot coerce without a type coercion"
> > >
> > > I've managed to get around it by defining a
> type 'ArrayRef[Thing]'
> > >
> > > Eg
> > > Subtype 'ArrayRef[Thing]'
> > > => as 'ArrayRef'
> > > => where {
> > > foreach (@{$_} ....
> > > };
> > >
> > > Coerce 'ArrayRef[Thing]'
> > > => from 'ArrayRef'
> > >
> > > But this means
> > > A) I'm essentially reimplementing ArrayRef
> each time.
> > > B) It always coerces!
> > >
> > > It should ideally check before it coerces...
> > >
> > > Anything I can do to improve on this?
> > >
> > >
> > >
> > >
> > >
> > > Also, I'd like to be able to declare
> something like
> > >
> > > has 'foo' => ( is=>'rw',
> > > delegate=> sub { Foo->instance }, handles
> =>[qw/x y z/] )
> > >
> > > Where, if no value is passed in to foo() on
> construction,
> > the accessor
> > > created for foo() will always trigger the
> delegate sub but will not
> > > store anything in the object in the way default
> does.
> > >
> > >
> > > I tried this ..
> > >
> > > has 'foo' => ( is=>'rw',
> > > isa=>'Object', handles=> [qw/meth1
> meth2 meth3/]);
> > >
> > > around 'foo' => sub {
> > > my ($next,$self,@args) = @_;
> > > if (@args) {
> > > return $self->$next(@args);
> > > } else {
> > > return $self->$next() ||
> Foo->instance();
> > > }
> > > };
> > >
> > > But got error:
> > >
> > > Cannot delegate meth1 to meth1 because the value
> of foo is not
> > > defined...
> > >
> > >
> > > Is there some way to do this?
> > >
> > > Thanks
> > >
> > > Tom
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Sartak [mailto:sar...@gmail.com]
> > > > Sent: 07 January 2009 12:39
> > > > To: Howe, Tom (IT)
> > > > Cc: ch...@prather.org; Yuval Kogman; Stevan
> Little;
> > > moose@perl.org
> > > > Subject: Re: Possible to disable/rename
> meta() method
> > > >
> > > > On Wed, Jan 7, 2009 at 4:49 AM, Howe, Tom
> (IT)
> > > > <tom.h...@morganstanley.com> wrote:
> > > > > Would be nice to be able to optionally
> rename or
> > > prefix it.
> > > > >
> > > > > I don't think a object meta class
> should add
> > > methods to the
> > > > main interface unless the object
> specifically needs to
> > > expose them.
> > > > >
> > > > > So by default there could be a
> _moose_meta()
> > > method and an
> > > > easy way to create a meta() ->
> _moose_meta()
> > > handler if
> > > > required (per class). This could be a global
> option if
> > > want
> > > > to retain compatibility with existing
> modules that
> > > require it.
> > > >
> > > > Yes, we all agree that it would be useful to
> give
> > > users the
> > > > ability to rename or not install a meta. The
> problem
> > > is that
> > > > in quite a few places in Class::MOP, Moose,
> and all of MooseX, we
> > > > call $pkg->meta with the expectation
> > > that it'll be
> > > > there and return the metaclass.
> > > >
> > > > It's just a small design problem, one we
> can fix
> > > with enough
> > > > grunt work. :)
> > > >
> > > > >
> > > > > Thanks
> > > >
> > > > Shawn
> > > >
> > > > > Ps. How do I subscribe to the mail
> list?
> > > >
> > > > Send mail to moose-subscr...@perl.org.
> > > >
> > >
> --------------------------------------------------------
> > >
> > > NOTICE: If received in error, please destroy and
> notify
> > sender. Sender
> > > does not intend to waive confidentiality or
> privilege. Use of this
> > > email is prohibited when received in error.
> >
> >
> >
> >
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify
> sender. Sender does not intend to waive confidentiality or
> privilege. Use of this email is prohibited when received in
> error.
