Re: Should I coerce a DBIC schema from HashRef?

[John Napiorkowski]

Bill,

I've done this a lot in the past, as well as a few other approaches.  In the 
end I've come to the conclusion that although off the top it seems like a nice 
interface, it doesn't grow old well and can be confusing to people trying to 
read your code.  I now tend to think that a consuming class should only build 
its objects when and if it needs some way to influence how they are built.  
Otherwise over the long term you end up with a confusing interface with a lot 
of stuff completely unrelated to the actual functioning of the class.  And it 
harder to test correctly.

I'm not sure what a better approach could be, but lately I've been taking the 
idea of having dedicated builder classes.  I know that sounds heavy handed, but 
at least it has the upside that my concerns are more carefully separated.

Good luck and very interested where this thread goes!

John



>
> From: Bill Moseley 
>To: moose@perl.org 
>Sent: Tuesday, September 4, 2012 2:07 PM
>Subject: Should I coerce a DBIC schema from HashRef?
> 
>Looking for a bit of guidance on design.
>
>I have a growing number of classes that require a DBIx::Class "schema"
>attribute.  These classe are used as Models in Catalyst (where they get the
>Catalyst app's schema passed in to the constructor), but they are also used
>in command line tools and cron jobs.
>
>It makes sense to coerce a URI object from a string, and even a DateTime
>from an integer or a string -- and MooseX::Types::DateTime and
>MooseX::Types::URI do that. But MooseX::Types::DBIx::Class does not coerce
>a schema object.
>
>Is there any reason I would not want to coerce a schema from a hashref?
>
>I guess another option would be a role that includes individual attributes
>for schema class, dsn, user, passwords, and \%options and use a
>_build_schema method.   This is an approach I've used in the past.
>
>BTW, I used DBIC as a familiar example, but many of my classes need more
>than just a DBIC schema -- they often need a logger, and a few other
>classes so this question isn't limited to building a schema object.
>
>-- 
>Bill Moseley
>mose...@hank.org
>
>
>

Re: MXT::Parameterizable still maintained?

[John Napiorkowski]

I've been trying to fix this in my spare time, but it was always a bit of a 
hack and I am having a lot of trouble syncing it with some of the deeper 
changes in the newer Moose's.  Also, since my company doesn't sponsor this work 
I have to use my limited spare time, which makes it slower as well.  Would 
appreciate any, thoughts, assistance anyone can give.  At this point in time I 
can't pinpoint the exact problem.

John




>
> From: Jesse Luehrs 
>To: Caleb Cushing  
>Cc: moose@perl.org 
>Sent: Tuesday, March 20, 2012 5:36 AM
>Subject: Re: MXT::Parameterizable still maintained?
> 
>On Fri, Mar 16, 2012 at 12:26:36PM -0500, Caleb Cushing wrote:
>> what's up with this? 0.08 breaks everywhere
>
>Seems to me like filing a bug report and contacting the author directly
>(he's regularly on IRC) would be a much easier way to get help with
>this.
>
>-doy
>
>
>

Re: OO Design Principles/Patterns

[John Napiorkowski]

- Original Message -
> From: Steve 
> To: Stevan Little 
> Cc: Moose ML ; John Napiorkowski 
> Sent: Tuesday, October 11, 2011 11:19 AM
> Subject: Re: OO Design Principles/Patterns
> 
> John and Stevan,
> 
> Thank you both for your comments.  This is pretty heady stuff for 
> someone who went to college to get a business degree :)

I have degrees in Philosophy, English and Performance Studies, so join the 
Club! :)

> 
> I will definitely take a look at all the resources referenced, and offer 
> one more that I stumbled across after my initial message: 
> http://www.bryanesmith.com/documents/a2pm/design-patterns-03-16-2011.pdf.  
> It is from a presentation given at a PM meeting in Ann Arbor, MI.  
> Interestingly, of the five patterns described using Moose, (Singleton, 
> Decorator, Adapter, Proxy, and Composite) there was no mention about the 
> applicability of the pattern when using perl.  That said, I do agree 
> that some don't appear to be particularly relevant to our language of 
> choice!
> 
> Thanks again,
> Steve
> On 10/11/2011 10:01 AM, Stevan Little wrote:
>>  On Oct 11, 2011, at 9:02 AM, John Napiorkowski wrote:
>>>>  From: Steve
>>>>  To: "moose@perl.org"
>>>>  Sent: Tuesday, October 11, 2011 8:50 AM
>>>>  Subject: OO Design Principles/Patterns
>>>> 
>>>>  As someone who arrived somewhat late to the OO game, I have take 
> every opportunity to learn some of the principles of OO design and use.  I 
> have 
> been using Moose for a couple of years, primarily in the context of Catalyst 
> and 
> HTML::FormHandler.  Lately though, I am studying the book 'Design Patterns - 
> Elements of Reusable Object-Oriented Software', which comes highly 
> recommended in OO land.
>>>> 
>>>>  I am wondering if anyone in the Moose community is: 1) aware of the 
> book, 2) used the patterns with Moose, and 3) has taken time to write about 
> implementing some of the patterns with Moose.
>>>> 
>>>>  The only thing I've seen referenced is how Moose 
> 'almost' can be used to create an abstract class with roles.  This might 
> be good subject matter for a book on Moose!
>>>> 
>>>>  Steve
>>>> 
>>>  Dear Steve,
>>> 
>>>  I sorta started a project like this once, but got lazy and never got 
> past https://metacpan.org/release/Patterns-ChainOfResponsibility (not sure if 
> that is the most awesome example of the CoR pattern either)
>>> 
>>>  I think the thing was I started to think that those patterns, while 
> interesting, are not universally applicable to all languages and styles.  For 
> example, a lot of the patterns seem to be to be how to make flexible code 
> when 
> you are using a statically compiled languages.  As a result I figured it 
> would 
> be better to wait a few years and see just exactly how people use Moose to 
> good 
> effect.  Perhaps the community is starting to approach that critical 
> knowledge, 
> although I doubt I have it!
>>> 
>>>  I guess even so, having such a thing would not be a bad exercise, and 
> serve as a good bit of advocacy as well as help form a bridge for programmers 
> coming from other languages.
>>> 
>>>  John
>>  John,
>> 
>>  Actually, in the original book, several of the patterns were written in 
> Smalltalk, which is a very dynamic language. However it is also an insanely 
> strict OO-only language, so some things had to be invented in there.
>> 
>>  Steve,
>> 
>>  Mark Dominus has a great talk on this subject here ( 
> http://perl.plover.com/yak/design/ ) I highly suggest you give it a read, it 
> is 
> pretty short but gets some good points across.
>> 
>>  In general the Perl community (and many of the other dynamic language 
> communities) have decided that many of the original Gang of Four design 
> patterns, while nice examples of OO design, are not relevant/necessary/useful 
> as 
> much when you are not writing in C++/C#/Java or Smalltalk. And in fact some 
> people think (myself included) that several of the patterns exist due to 
> (what 
> we perceive as) deficiencies in the languages themselves ( 
> http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Criticism ).
>> 
>>  For instance, the simplest and most often cited/used/abused pattern is the 
> Iterator pattern. This is common in the Java standard libraries, is core to 
> the 
> language of C# and basically in Perl is written as:
>> 
>>     foreach my $item (@items) { ... }
>> 
>>  or
>> 
>>     map { ... } 

Re: OO Design Principles/Patterns

[John Napiorkowski]

>
>From: Steve 
>To: "moose@perl.org" 
>Sent: Tuesday, October 11, 2011 8:50 AM
>Subject: OO Design Principles/Patterns
>
>As someone who arrived somewhat late to the OO game, I have take every 
>opportunity to learn some of the principles of OO design and use.  I have been 
>using Moose for a couple of years, primarily in the context of Catalyst and 
>HTML::FormHandler.  Lately though, I am studying the book 'Design Patterns - 
>Elements of Reusable Object-Oriented Software', which comes highly recommended 
>in OO land.
>
>I am wondering if anyone in the Moose community is: 1) aware of the book, 2) 
>used the patterns with Moose, and 3) has taken time to write about 
>implementing some of the patterns with Moose.
>
>The only thing I've seen referenced is how Moose 'almost' can be used to 
>create an abstract class with roles.  This might be good subject matter for a 
>book on Moose!
>
>Steve
>


Dear Steve,

I sorta started a project like this once, but got lazy and never got 
past https://metacpan.org/release/Patterns-ChainOfResponsibility (not sure if 
that is the most awesome example of the CoR pattern either)

I think the thing was I started to think that those patterns, while 
interesting, are not universally applicable to all languages and styles.  For 
example, a lot of the patterns seem to be to be how to make flexible code when 
you are using a statically compiled languages.  As a result I figured it would 
be better to wait a few years and see just exactly how people use Moose to good 
effect.  Perhaps the community is starting to approach that critical knowledge, 
although I doubt I have it!

I guess even so, having such a thing would not be a bad exercise, and serve as 
a good bit of advocacy as well as help form a bridge for programmers coming 
from other languages.

John 

Re: defining my own parameterized types

[John Napiorkowski]

>
>From: Mark Wood-Patrick 
>To: moose@perl.org
>Sent: Friday, June 24, 2011 8:51 AM
>Subject: defining my own parameterized types
>
>
>I would like to add my own parameterized type e.g. I would like to be able to 
>create types like:
> 
>    SzStr[32]

I wrote http://search.cpan.org/perldoc?MooseX::Types::Parameterizable as a sort 
of exercise for this, would love for people to give it a go and let me know how 
it works out.


> 
>Which would allow me to specify the maximum size of a string that an attribute 
>can have and will validate the size of the data I’m storing in the attribute
> 
>Or to specify that an attribute is a secondary key in some DB like:
> 
>    DBKey[User]

http://search.cpan.org/dist/MooseX-Attribute-Dependent/ also seems interesting, 
not sure if either the above exactly fit the bill.


> 
>Where User is a Moose class that provides an in memory version of a DB record 
>and the attribute would be a weak reference to such an object
> 
>Is this currently possible? I looked at the docs for things like:
> 
>    
>http://search.cpan.org/dist/Moose/lib/Moose/Meta/TypeConstraint/Parameterized.pm
> 
>but that has:
> 
>METHODS 
>This class is intentionally not documented because the API is confusing and 
>needs some work.
> 
>I would appreciate any pointers to examples or docs
>Thanks in advance
>Mark Wood-Patrick
>  
>
>
>
>
>
> 
> 
> 
>
>

Re: MooseX::Types coercions and $self

[John Napiorkowski]

- Original Message 
> From: Evan Carroll 
> To: "moose@perl.org ML" 
> Sent: Fri, December 17, 2010 3:00:06 PM
> Subject: MooseX::Types coercions and $self
> 
> Copied from http://stackoverflow.com/q/4473327/124486
> 
> The below is not as  well formatted:
> 
> Is there anyway to get $self into a MooseX::Types  coercion? I have
> other data in the object that I want to use to seed my  coercion from a
> String to an Object. Alternatively, is there anything  like
> Class::MOP's initializer that will permit me to do this -- it  would
> have to fire before the type checks.
> 
> Requested pseudo  code:
> 
> with 'DBHandle';
> has 'database' => ( isa => 'Str', is  => 'ro', default => 'Db' );
> has 'schema' => ( isa => 'Str', is  => 'ro', default => 'schema' );
> has 'table' => ( isa => 'Str', is  => 'ro', default => 'column );
> 
> has 'columns' => ( isa =>  DBCols, is => 'ro', default => sub {[qw/foo
> bar baz/]} );
> Here, I  want "columns" to coerce to a DBCols -- an ArrayRef of DBCol's
> (objects) --  requiring the use of catalog, schema, and col attributes
> found in the class,  and with a dbh/singleton provided by DBHandle.
> 
> To make this less-pseudo,  the actually situation is only slightly more
> complex. I was able to  accomplish the above with around, now what I
> want I to do is create an  attribute trait that would permit this
> syntax:
> 
> has 'column_id' =>  (
>   isa => Int
>   , is => 'ro'
>   , traits =>  ['DBKey']
>   , default => 5
>   , column =>  'foo'
> );
> Where the attribute trait column provided by DBKey, coerces to  DBCol
> the same way that the above columns would: this would require  the
> ability to access the classes database, schema, table, and again  the
> singleton for the dbh.

I actually published 
http://search.cpan.org/perldoc?MooseX::Types::Parameterizable as an experiment 
in starting to provide this capacity.  I know someone did some work along these 
ways over at http://search.cpan.org/perldoc?MooseX::Types::DBIx::Class building 
on top of that.  Last time I thought about this issue I also thought an 
attribute trait might be the right way to go, but I put it aside a bit to see 
what, if anything, was useful with MXT:Parameterizable.  Mst told me this was 
probably achievable using just MXT:Structured for what that's worth, although I 
could just be mis-remembering

john

> 
> -- 
> Evan Carroll - m...@evancarroll.com
> System Lord of the  Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011
> 


  

Trouble with type constraint equality between latest Moose and MX:Types

[John Napiorkowski]

Hey,

So the latest Moose introduced a change with the default response to type 
constraint equality.  In the past type constraints were basically presumed 
equal unless the were proven not.  Now unless two type constraints meet the 
equality test they are presumed not equal.  However this caused incompatibility 
with MooseX::Types since the one main way for two types to be equal was if 
thier redaddr was the same.  Since MX:Types wraps type constraints inside a 
decorator, this will always not be the case, even when the underlying wrapped 
type constraint was the same.

Fixes for this have been commited to the repo for Moose, and a change to 
MX:Types as well.  Unfortunately this will require a cascade of updates for 
other MX:Type based modules such as MX:T:Structured.  The first step is to get 
the Moose patch reviewed, etc.  Please let me know if things are in order.  I 
will not be on IRC during the US holiday but will check email.

Thanks!

John Napiorkowski



  

Re: Proposal: "Moose, the *modern* [not "post-modern"] Perl 5 Object System"

[John Napiorkowski]

- Original Message 
> From: Chris Prather 
> To: Shlomi Fish 
> Cc: moose@perl.org
> Sent: Sun, April 11, 2010 11:45:33 AM
> Subject: Re: Proposal: "Moose, the *modern* [not "post-modern"] Perl 5 Object 
>  System"
> 
> On Sun, Apr 11, 2010 at 11:27 AM, Shlomi Fish <
> ymailto="mailto:shlo...@iglu.org.il"; 
> href="mailto:shlo...@iglu.org.il";>shlo...@iglu.org.il> wrote:
> Hi 
> all,
>
> I hope I'm not going to start a flamewar or appear as too 
> domineering (which I
> know has been an ongoing problem with me) but I'd 
> like to make the proposal in
> the subject:
>
> {{{
> 
> Let's start referring to Moose as "the modern Perl 5 Object System" instead 
> of
> "the post-modern Perl 5 Object System".
> }}}
>
> 
> The reason is that "post-modern" tends to have very bad connotations in 
> art
> and philosophy, outside the narrow context of Larry Wall's 
> presentation "Perl,
> the first post-modern language", which even many 
> Perl programmers are not
> familiar with, and may give people who are 
> first introduced to the topic the
> wrong idea.

[citation 
> needed]

When I was in University, admittedly a few years ago now, 
> Post
Modernism and one of it's tools Deconstructionism was very much 
> the
rage. In the years since I have left university I haven't seen 
> these
bad connotations. Do you have references?

As someone with an undergraduate degree in literature and philosophy I tend to 
agree.  However "post modern' has a pretty nebulous definition.  For example 
deconstructionism, which tends to fall under the PM umbrella, does provoke 
strong reactions amongst many philosophers (including myself).  However 
deconstructionism != post modernism.

I think the core concepts of post modernism tend to include ideas like mixing 
over pure, inversion of hierarchies, etc and for that I think it works for 
Moose.  At this point the  catchphrase 'postmodern OO' is well established even 
if misunderstood.

I think 'Post' is also good because it implies we are moving beyond something, 
presumably a lot of the cruft which lead Perl to have such a terrible imagine.  
For me I can't see changing this is going to help us, although I appreciate 
your thinking through the social perception issue. Certainly I believe this is 
something the Perl community does need to pay attention to

john

>On the other hand 
> saying that Moose is a *modern* Object System
> will normally immediately 
> give people the right idea.
>
> I know that it's cute to call Moose 
> the "post-modern OOP system" but it may
> either make people wonder what 
> the hell we mean, or may even give the wrong
> impression, so I suggest we 
> drop it.

One of the few popular posts in my blog explained this in 
> detail. I
refer you to 
> http://chris.prather.org/why-moose-is-post-modern.md.html.
Do you have 
> evidence that it *is* making people wonder what the hell
we mean?

> 
> I don't mind working on the patch to the site and to 
> href="http://Moose.pm";>Moose.pm to change all
> "post-modern"'s to 
> "modern"'s, but I'd like to know it would be accepted
> first.

I 
> for one like the Post-Modern epithet. Trying to suggest a package
named Moose 
> will somehow seem more serious by changing "post modern"
to "modern" is I 
> think ridiculous. In four years I have only felt the
need to defend the "Post 
> Modern" description once (last April), and
that was because the people 
> questioning Moose had (what I felt was) a
misunderstanding of the concept of 
> Post Modernity[1].

Ultimately if people are objecting to Moose because it 
> claims to be
Post Modern, they have deeper issues, and probably need to 
> seek
professional help.

-Chris

[1] I honestly shouldn't have 
> bothered, but someone was *wrong* on the internet.


  

Re: Moose-0.97 caused a DBIx::Class test failure

[John Napiorkowski]

- Original Message 

> From: Koichi Nakatani 
> To: moose@perl.org
> Sent: Wed, February 10, 2010 5:16:06 PM
> Subject: Moose-0.97 caused a DBIx::Class test failure
> 
> Before installing Moose-0.97:
> $ prove -l t/storage/replication.t
> t/storage/replication.t .. 1/? # Using Moose version 0.96 and
> MooseX::Types version 0.21
> t/storage/replication.t .. ok
> All tests successful.
> Files=1, Tests=132,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.64
> cusr  0.10 csys =  0.78 CPU)
> Result: PASS
> 
> After Moose-0.97:
> $ prove -l t/storage/replication.t
> t/storage/replication.t .. 1/? # Using Moose version 0.97 and
> MooseX::Types version 0.21
> Deep recursion on subroutine
> "DBIx::Class::Storage::DBI::Replicated::Replicant::debugobj" at
> [...]/DBIx-Class-0.08118/lib/DBIx/Class/Storage/DBI/Replicated.pm
> line 758.
> Deep recursion on subroutine
> "DBIx::Class::Storage::DBI::Replicated::debugobj" at
> [...]/DBIx-Class-0.08118/lib/DBIx/Class/Storage/DBI/Replicated/Replicant.pm
> line 69.
> 
> ...and the test does not seem to come to an end.
> 
> I got the result with (hand-built) perl 5.10.1 on Mac OS X 10.6.

There's a new Moose on the way to CPAN (should arrive on local mirrors soon) 
that fixes this problem.  Hopefully you'll be able to upgrade shortly.

John Napiorkowski



  

Re: Time for a rewrite

[John Napiorkowski]

Hi,

Since I'm speaking generally, rather than responding, I hope top posting is 
considered acceptable.

Things I'd like to see done differently (not exactly things I don't like, but 
just irritate me)

1) See Moose more as a way to hook up a bunch of suger, like MX:Declare, 
advanced types and exceptions, possible event multi methods and the stuff in 
Moose::Autobox.

2) So more deep stuff moved to MOP, like Roles (not sure if this is possible, 
but you said anything :) )

3) Type constraints decoupled from Moose and some things changed under the hood 
to make it easier to improve error messages for things like MX:T:Structured and 
other changes so that slurpy in MX:T:Structured doesn't have to be an evil 
hack.  A stand alone type constraint system that makes it easier for me to 
complete the dependent and faceted type stuff sitting inthe repo for like a 
year would be nice.  And of course a sweet MooseX::Declare style syntax.  Then 
we can end the stringy types versus MooseX::Types style types issue for good.

4) Lispy conditionals (I know it's been said before, but I think we are closer 
now to making this workable)



- Original Message 
> From: Yuval Kogman 
> To: moose@perl.org
> Sent: Tue, November 10, 2009 2:49:44 PM
> Subject: Time for a rewrite
> 
> Just kidding ;-)
> 
> But there is some truth:
> 
> 1. MooseX::Declare has gained us a lot of insight on what we can do
> substantially better
> 2. We learned how to structure extensibility with traits
> 3. we got a bunch of stuff wrong (ranging from slightly annoying to "oops,
> sorry")
> 4. we have probably gotten things wrong that we don't know about
> 
> Fortunately the MOP api is designed to be extensible, the only unanswered
> question is what defaults to we ship.
> 
> I think it's time to start thinking about how to get Perl's 'use 5.010' for
> Moose, in one form or another.
> 
> Fortunately, Perl kinda sorts this out for us:
> 
> use Moose 0.92 qw(foo bar);
> 
> This will:
> 
> 1. require Moose
> 2. call Moose->VERSION(0.92) from the POV of the caller
> 3. call Moose->import(qw(foo bar))
> 
> In terms of infrastructure I think that doesn't take much else,
> Moose::VERSION will simply init_meta slightly differently, and the import
> routine can act accordingly (it is already capable of detecting
> pre-initialized metaclasses).
> 
> I think if we structure Moose's features in a more plugin like architecture,
> where the metaclass instance can augment or replace the Moose::Exporter
> stuff to some extent, it should be trivial to make a future and backwards
> compatible way to keep things clean.
> 
> Using a metaclass centered approach we can just let polymorphism ensure we
> have all our opportunities open.
> 
> So anyway, I'll reply to myself with what I dislike about Moose in its
> current form, and I hope you do the same



  

Re: MooseX::Types to core?

[John Napiorkowski]

- Original Message 
> From: fREW Schmidt 
> To: Hans Dieter Pearcey 
> Cc: moose 
> Sent: Wednesday, September 16, 2009 11:53:35 AM
> Subject: Re: MooseX::Types to core?
> 
> On Tue, Sep 8, 2009 at 9:32 AM, Hans Dieter Pearcey wrote:
> 
> > Whenever we've talked about coring MooseX modules, it's mostly been MXAH
> > and
> > MooseX::Types.  Does anyone have any changes they'd like to see in
> > MX::Types
> > before it becomes, say, Moose::Types?  (Moose::TypeConstraints?)
> >
> > For myself:
> >
> > * Warn/die on subtype DeclaredType => as Foo => where { ... } (accidental
> >  stringification) -- I thought someone had fixed this, but it came up as a
> >  silent failure recently, so maybe not in all cases?
> >
> > * Standardize on a best practice for parameterized non-global types (e.g.
> >  ArrayRef[MyObject] vs. ArrayRefOfMyObject) and make documentation use it
> >  consistently
> >  * if the former, the RT bug about coercions needs to be fixed
> >
> > * smarter renaming of imports -- e.g. if you try to import Foo from a type
> >  library, with -prefix => 'My', it'd really be nice to get to_MyFoo and
> >  is_MyFoo helpers instead of Myto_Foo and Myis_Foo
> >
> > * MooseX::Types::Moose -> Moose::Types::Native (maybe)
> >
> > * Should Structured be included?
> >
> > hdp.
> >
> 
> 
> +1 for Types w/o Moose.
> 
> But back on the original topic, something that bothers me about MX::Types is
> that you can't have : in a type name.  I mostly use that for signature stuff
> in catch blocks w/ TryCatch.  Although I guess the existent Moose types
> system allows for : in the names so maybe the inclusion would resolve that
> issue.

Since a MooseX::Type type constraint is basically an exported function I don't 
think we'd every get ':" supported as part of the name.  The string based types 
built into Moose allow this and anything else you can put into a string.

Can you provide a more detailed example of your use and hoped for syntax?

John

> 
> -- 
> fREW Schmidt
> http://blog.afoolishmanifesto.com



  

Re: MooseX::Types to core?

[John Napiorkowski]

- Original Message 
> From: Chris Prather 
> To: John Napiorkowski 
> Cc: moose 
> Sent: Tuesday, September 8, 2009 1:41:39 PM
> Subject: Re: MooseX::Types to core?
> 
> On Tue, Sep 8, 2009 at 1:32 PM, John Napiorkowskiwrote:
> >
> >
> >
> >
> > - Original Message 
> >> From: Hans Dieter Pearcey 
> >> To: moose 
> >> Sent: Tuesday, September 8, 2009 1:21:51 PM
> >> Subject: Re: MooseX::Types to core?
> >>
> >> Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009:
> >> > I think the suggestion is that type constraints be completely divorced
> >> > from Moose so that other possibly non-Moose/CMOP projects can use it w/
> >> > o requiring Moose/CMOP.  Or is that missing the mark John?
> >
> > I think cut from Moose yet, but not from CMOP.  I think we will need to 
> > think 
> the
> > relationship between CMOP and TC is complex.  TC would be build on CMOP,
> > but CMOP would want a TC system for full functionality (as if someday we 
> decided
> > to move some of the method signature checking to CMOP, which is where I 
> > think 
> it
> > would be most useful, but I could be wrong).
> >
> >>
> >> I understand the suggestion, and it is a reasonable one.  Why would such a 
> type
> >> constraint implementation be mutually exclusive with MooseX::Types going 
> >> into
> >> core?  Wouldn't we just reimplement Moose::Types in terms of this new
> >> independent code?
> >>
> >> hdp.
> >
> > Yeah, totally.  As per my last email I agree with the sentiment here, with 
> > the 
> caveat
> > regarding backcompatibility.
> 
> CMOP has always been (in my mind) a formalization of Perl5's implicit
> MOP. While it's not 100% accurate that is the general driving
> principle from what conversations we've had over the years.
> 
> I like the idea of having TCs spun off into their own creature and
> Moose::Types built upon this creature ... but I hesitate to say things
> like Method signature checking should go into CMOP since there is no
> such facility in Perl5 itself and such a facility doesn't "compile
> away clean" like say Roles do. That said ... CMOP would should

It's possible the way we are doing it now with MooseX::Declare is essentially 
the
correct way, isolating the method sig stuff in it's own dist (as well as the 
actual
parsing of the signature string in it's own class).  I'm not sure.  I can see 
either
side.

However, I think the interface for the signature might be usefully built in, 
rather
than the actual implementation.  That would offer guidance to people writing 
the implementations, although right now we just have the one.

> (eventually) have some facility for introspecting Lexical Types since
> those do exist in Perl5 (and as such we can push their implementation
> into something more useful).
> 
> -Chris

I don't know enough about Perl guts, but when people ask me what I'd like
to see in Perl 5.12 I usually say more exposure of these lower level bits to
make is easier (and probably faster and more stable) to expand upon them.
Maybe we already have what we need though.  I'm not enough of a C programmer
to be able to tell.

john


  

Re: MooseX::Types to core?

[John Napiorkowski]

- Original Message 
> From: Hans Dieter Pearcey 
> To: moose 
> Sent: Tuesday, September 8, 2009 1:21:51 PM
> Subject: Re: MooseX::Types to core?
> 
> Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009:
> > I think the suggestion is that type constraints be completely divorced  
> > from Moose so that other possibly non-Moose/CMOP projects can use it w/ 
> > o requiring Moose/CMOP.  Or is that missing the mark John?

I think cut from Moose yet, but not from CMOP.  I think we will need to think 
the
relationship between CMOP and TC is complex.  TC would be build on CMOP,
but CMOP would want a TC system for full functionality (as if someday we decided
to move some of the method signature checking to CMOP, which is where I think it
would be most useful, but I could be wrong).

> 
> I understand the suggestion, and it is a reasonable one.  Why would such a 
> type
> constraint implementation be mutually exclusive with MooseX::Types going into
> core?  Wouldn't we just reimplement Moose::Types in terms of this new
> independent code?
> 
> hdp.

Yeah, totally.  As per my last email I agree with the sentiment here, with the 
caveat 
regarding backcompatibility.



  

Re: MooseX::Types to core?

[John Napiorkowski]

- Original Message 

> From: Hans Dieter Pearcey 
> To: moose 
> Sent: Tuesday, September 8, 2009 12:43:45 PM
> Subject: Re: MooseX::Types to core?
> 
> Excerpts from Stevan Little's message of Tue Sep 08 12:39:01 -0400 2009:
> > The TC objects use C::MOP level attributes though, so no types.
> > 
> > Yes, I think it could be totally pushed outside of Moose, however a  
> > few things would need fixing, such as the type registry.
> 
> Just to be sure I'm not missing something:
> 
> This has nothing to do with coring MooseX::Types, right?  It's in the same
> space as Moose::Util::TypeConstraints, not Moose::Meta::TypeConstraint.
> 
> hdp.

Honestly, I'd argue that moving MooseX::Types to core is the opposite of what 
I'd like to see.  What I'd what to see is a more cleanly and clearly defined TC 
system, with all the bits needed divorced from Moose (including something with 
the Registry that Stevan mentioned) and then Moose would leverage that and 
possible CMOP might define some interfaces and apis around like (like function 
support and attribute type checking).  I'm not sure if that's the direction 
everyone agrees with though :)

john



  

Re: MooseX::Types to core?

[John Napiorkowski]

- Original Message 

> From: Hans Dieter Pearcey 
> To: moose 
> Sent: Tuesday, September 8, 2009 10:32:50 AM
> Subject: MooseX::Types to core?
> 
> Whenever we've talked about coring MooseX modules, it's mostly been MXAH and
> MooseX::Types.  Does anyone have any changes they'd like to see in MX::Types
> before it becomes, say, Moose::Types?  (Moose::TypeConstraints?)
> 
> For myself:
> 
> * Warn/die on subtype DeclaredType => as Foo => where { ... } (accidental
>   stringification) -- I thought someone had fixed this, but it came up as a
>   silent failure recently, so maybe not in all cases?
> 
> * Standardize on a best practice for parameterized non-global types (e.g.
>   ArrayRef[MyObject] vs. ArrayRefOfMyObject) and make documentation use it
>   consistently
>   * if the former, the RT bug about coercions needs to be fixed
> 
> * smarter renaming of imports -- e.g. if you try to import Foo from a type
>   library, with -prefix => 'My', it'd really be nice to get to_MyFoo and
>   is_MyFoo helpers instead of Myto_Foo and Myis_Foo
> 
> * MooseX::Types::Moose -> Moose::Types::Native (maybe)
> 
> * Should Structured be included?
> 
> hdp.

I've spent a lot of time thinking about the intersections of Moose and Type 
Constraints.  My general conclusion is that I think it's correct that TC and 
Moose general be detached (and I'd love to see more detachment) since people 
have uses for type constraints beyond Moose.  That said, I think there is a 
bigger connection between TC and Class::MOP, since my imagination is telling me 
that Moose will eventually be more and more about suger and use, and 
functionality will migrate toward CMOP.  For example, I know we keep kicking 
around the idea that Roles should be in CMOP.  I also personally think some of 
the bits in MooseX::Declare related to method signatures should either be in 
CMOP or at least coordinated with a more rigorous interface defined by CMOP. So 
again, my imagination is saying type constraints are build on top of CMOP, and 
consumed by Moose or others.

My longish term plans for this would include a default set of types that would 
be a superset of the current (probably would include datetime stuff and maybe 
set stuff that is useful to the database people)  as well as a superset of 
functionality.  I'd probably build something out from the ideas in the 
MooseX::Dependent stuff in the repo, so that all types could be parameterzied 
or faceted (making it easy to say subtype ShortString, as Str[MaxLength=>5]; ) 
and adding some facility for traits or roles to types.  This would be so you 
could define a trait like 'hasMinSize' and it could be meaningfully conposed 
into any TC that defines a 'size' method.  something sorta like:

subtype AtLeast3Characters,
   as Str[MinSize=>3],
   with hasMinSize,
   where 'size' {
  my ($tc, $value) = @_;
  return $tc->{MinSize} > length $value;
   };

Just a wild guess right now.

John


  

Re: subtyping parameterized types

[John Napiorkowski]

Hans, sorry I duped you on this message.



- Original Message 
> From: Hans Dieter Pearcey 
> To: moose 
> Sent: Thursday, September 3, 2009 8:52:02 PM
> Subject: subtyping parameterized types
> 
>   subtype Foo, as ArrayRef[Str], where { @$_ < 5 };
> 
> Foo is now a parameteriz*able* type, not a parameteriz*ed* type; that is,
> in theory (if the MooseX::Types decorators allow it), you can:
> 
>   has foo_classes => (isa => Foo[ClassName]);
> 
> since ClassName is a subtype of Str.
> 
> This surprised me, and means that Native::Trait::Array/Hash totally don't work
> with subtypes of parameterized types.

We had a discussion about this a while back when I was adding
parameterization support to MooseX::Types.  I think this was a least of
evils, let's punt until we really understand what we want.  I
duplicated the behavior for MooseX::Types::Structured, btw, you can
reparamterize a structured type as long as you don't contradict the
existing type.  I took a similar approach to the stuff in the repo
under MooseX::Dependent.

As I said, this was the best idea we could come up with without any real use 
cases.  Seems we have one now :)

> 
> I'm poking at this now.  Any insight is welcome.
> 
> hdp.



  

Re: More on Native Traits

[John Napiorkowski]

- Original Message 
> From: Stevan Little 
> To: Jesse Luehrs 
> Cc: Hans Dieter Pearcey ; moose 
> Sent: Wednesday, August 26, 2009 2:26:35 PM
> Subject: Re: More on Native Traits
> 
> Hmmm,
> 
> Okay, well to fix the first case I think we need to simply add a 
> is_any_parent_parameterized or something to the core TC objects and we can 
> check 
> that when creating the accessor. This will catch the type alias cases and 
> maybe 
> a few others (anon-subtypes).
> 
> For the second case, perhaps we need a new type of TC object that is a 
> parameterized type with a where clause. Instead of the accessor just checking 
> the parameter type it will also do a check on the entire value itself after 
> the 
> operation has been completed.
> 
> Thoughts?
> 
> - Stevan

I ran into similar trouble when playing with the MooseX::Dependent stuff in the 
git repo, mostly when adding dependencies to existing parameterized types, I 
had to jump through a lot of hoops.

>From my perspective I foresee all types someday being 'parameterized' (or 
>facted, whatever) so that we can support basic facet build in to types, like 
>ArrayRef(of(Int), hasMaxLength(10)) and Str(hasPattern(qr(/d/d-/d/d/d/d/)) or 
>something like that.  So somewhat to test this up the stack would be useful I 
>think.

john

> 
> On Aug 26, 2009, at 1:06 PM, Jesse Luehrs wrote:
> 
> > On Fri, Aug 21, 2009 at 09:22:26AM -0700, Hans Dieter Pearcey wrote:
> >> As far as I know, nothing else needs to be done for this branch.  Jesse, 
> Chris,
> >> or Shawn -- anything I missed?
> > 
> > Something brought up by mo on #moose a day or two ago:
> > 
> >  package Foo;
> >  use Moose;
> >  use Moose::Util::TypeConstraints;
> > 
> >  subtype 'Bar', as 'ArrayRef[Int]';
> > 
> >  has bar => (
> >  traits => [qw(Array)],
> >  is  => 'ro',
> >  isa => 'Bar',
> >  default => sub { [] },
> >  handles => {
> >  push_bar => 'push',
> >  },
> >  );
> > 
> >  my $foo = Foo->new;
> >  $foo->push_bar('baz') # this doesn't throw an error
> > 
> > Basically, the only case that we actually check for when deciding
> > whether the accessor should do a type constraint check is when the
> > constraint is literally 'ArrayRef[Foo]'. I don't think that any
> > auto-generated accessors should allow the type constraint to be
> > violated.
> > 
> > The most straightforward solution I can see is to figure out if the type
> > constraint is a bare wrapper around the appropriate parameterized
> > constraint (like above), if it is, then search through the hierarchy to
> > find the proper constraint to check. If it's not, then we really have no
> > choice but to do a full check of the constraint on every modification -
> > consider constraints like
> > 
> >  "subtype 'Foo', as 'ArrayRef[Int]', where { sum(@$_) < 5 };
> > 
> > - there's really no way to express that as a partial type constraint
> > check without doing really ugly things.
> > 
> > Thoughts? Better solutions?
> > 
> > -doy



  

Re: Types and Constraints

[John Napiorkowski]

--- On Wed, 4/29/09, Darren Duncan  wrote:

> From: Darren Duncan 
> Subject: Re: Types and Constraints
> To: moose@perl.org
> Date: Wednesday, April 29, 2009, 6:01 PM
> Zbigniew Lukasiak wrote [privately]:
> > On Wed, Apr 29, 2009 at 10:28 PM, Darren Duncan 
> wrote:
> >> Zbigniew Lukasiak wrote:
> >>> It seems that in the Moose terminology a Type
> is just a constraint
> >>> with a name.  This is different from
> other languages where the type of
> >>> a value does not change in time or in relation
> to the whole system.
> >>> You can copy the value and be sure that the
> copy has the same type you
> >>> can wait and check the value after some time
> and it's type would not
> >>> change, but if a value type is defined by it
> passing a constraint -
> >>> then these invariants do not hold.  For
> example think about a
> >>> constraint that checks if a date is in the
> past.
> >>> 
> >>> This is not to criticise this - I understand
> that it is just a
> >>> practical solution - I just want to know if
> there is a consensus that
> >>> it is OK to write Moose types like
> DateInThePast.
> >> In some languages a type is mostly just a named
> set of values, and so it is
> >> valid for the same value to belong to more than
> one type.  You see this in
> >> Perl 6 for example; when you define a subtype (eg,
> UInt is subtype of Int
> >> where ...) or a union type (eg, Scalar is union of
> Num|Str etc) values
> >> falling under those still belong to their original
> types but also to the new
> >> ones.  That said, even in those cases a value
> would still have just a single
> >> "root type", which is the type whose declaration
> allowed you to select (or
> >> "construct") that value in the first place, and
> any other types would not be
> >> re-introducing the value but just using it. --
> Darren Duncan
> > 
> > Hmm - sorry but I don't understand.   I
> was writing about the fact
> > that a value at one point can pass a particular
> TypeConstraint - and a
> > second later the same TypeConstraint on the same value
> can fail.  This
> > seems to me very different from the way types are used
> in any other
> > language - where if a value is of a particular type
> then it always
> > will.  There was nothing about subtypes in my
> question - only about
> > invariants.
> 
> Let me clarify, I do believe that all types are / should be
> invariant.  I believe that a type system is / should be
> pure and deterministic, and that what values are part of a
> type can not change except by changing the program source
> code that is the type's definition.  So anything that
> is impure, including testing what the current date is at
> runtime, can't / shouldn't be allowed in a type
> definition.  In other words, there can't / shouldn't be
> a type or TypeConstraint called DateInThePast; rather,
> DateInThePast should be a constraint applied at variable
> assignment time, associated with the variable and not a
> type.  The only thing that should be allowable as a
> TypeConstraint like this is, for example,
> DateBefore2009April, and even that is probably a bad design,
> but it is at least pure, and/but I would never do it. 
> But better yet, keep the TypeConstraint to just be eg
> "Date", which is invariant. -- Darren Duncan
> 

Just curious, how would you feel about an implimentation of dependent types 
where the functional element was predefined and more explicit, such as (syntax 
hypothetical and only partly implemented...)

dependent subtype DateBefore($upper_date DateTime),
  as $lower_date DateTime,
  where {
$lower_date < $upper_date;
  };

might be used like (mentally assume a coercion on the date string please):

## ->check($upper_date, $lower_date
DateBefore->check('01-01-2009', '01-01-2000'); ## ok
DateBefore->check('01-01-2009', '01-01-3000'); ## NOT ok

In this case the type is explicitly marked as functional and the requirements 
are known upfront and introspectable.  I guess the only issue for introspect 
and reusability is the fact that the meat of the constraint in in the coderef, 
but this could be solved with some sort of type trait mechanism.  Consider:

dependent subtype DateBefore($upper_date DateTime),
  as $lower_date DateTime,
  having isLessThan {
$upper_date;
  };


Still very hypothetical syntax but I hope you get the idea.  Curious to get 
your thoughts (or anyone else's)

jnapiorkowski

Re: factory class

[John Napiorkowski]

--- On Fri, 4/10/09, Rodrigo  wrote:

> From: Rodrigo 
> Subject: Re: factory class
> To: moose@perl.org
> Date: Friday, April 10, 2009, 3:11 PM
> >
> >
> > The  code I woud like to migrate to Moose uses
> the factory pattern in
> > several classes. So, is there a Moose-way to
> > implement a factory class ?
> >
> >
> Rolf, I recommend you take a look at the MooseX::IOC
> module, and the whole
> IOC suite for that matter, as they may serve your
> purposes.
> 
> http://search.cpan.org/~stevan/MooseX-IOC-0.02/lib/MooseX/IOC.pm
> 
> -rodrigo
> 

If you go that route, you should check out Bread::Board, which is the Moose 
based rewrite of IOC.

John

Re: RFC: How to overcome potential problems with before?

[John Napiorkowski]

--- On Wed, 3/4/09, MORGUN Alexander  wrote:

> From: MORGUN Alexander 
> Subject: RFC: How to overcome potential problems with before?
> To: moose@perl.org
> Date: Wednesday, March 4, 2009, 12:12 PM
> Hello,  
>   
> I've seen a lot of bugs with before on attributes. The
> last one in HTML::FormBuilder :) What is the good practice
> to do that? Stop using before on attributes? Use direct
> value access? Personally, i think that lazy + default is
> good, but i see much people (including me) using before
> everywhere, because it is handy. 

If given more than one way to do a task I would try to use the most 
semantically meaningful approach, makes understanding the code easier.  If 
that's not clear then try whatever is easier.  In this case I would usually 
favor either coercion or the lazy_build option if I wanted an attribute that 
needed to either be default created, dependent on other attributes, or inferred 
from incomplete or tangential incoming information.  When I see lazy_build I 
know right away what the author was intending, since that feature was added 
specifically to address this need.  Method wrappers were created for more 
general functionality, but are often used as a more sane approach to how to 
override methods in parent or delagated classes.  I'd recommend something like:

class Test {
 has 'a' => (is=>'rw', lazy_build=>1);

 method _a {
   # return whatever you want 'a' to contain.
 } 
}


Personally I tend away from rw attributes lately unless it's for true entity 
style classes, since I find they can leave the class in inconsistent or 
unforseen states.  But I don't know your entire need.  If you could describe 
the logical goal here, maybe we could find a better way for you to do this.

See "http://search.cpan.org/~stevan/Moose/lib/Moose/Cookbook/Recipe9.pod"; for 
more on the lazy_build if you need a refresh.

John

>   
> #!/usr/bin/perl -w  
> use MooseX::Declare;  
>   
> class Test {  
> has 'a' => (isa => 'Int', is
> => 'rw');  
>   
> before a {  
> $self->do_calculations;  
> }  
> method do_calculations {  
> #after a lot of refactorings in some cases
> we check the $self->a  
> $self->a;  
> }  
> }  
>   
> my $t = Test->new(a=>2);  
> print $t->a;


  

Re: advice on wrapping methods from a superclass

[John Napiorkowski]

- Original Message 
From: Jonathan Swartz 
To: moose@perl.org
Sent: Wednesday, February 11, 2009 3:55:50 AM
Subject: advice on wrapping methods from a superclass

CHI (http://search.cpan.org/~jswartz/CHI-0.091/lib/CHI.pm) is a Moose-based 
caching framework. There is a driver superclass (CHI::Driver) and various 
driver subclasses that implement different cache backends (CHI::Driver::File, 
CHI::Driver::Memcached, etc.) Drivers implement standard methods like remove() 
and clear(). e.g Currently, if you call $cache->remove(), it goes directly to 
the driver subclass.

The problem is that there are now legitimate reasons to "wrap" these methods at 
the CHI/Driver.pm superclass level (meaning, do something before and/or after 
the method). For example, I want to add an optional generic size-awareness 
feature (the cache can keep track of its own size), which means that we have to 
adjust size whenever remove() and clear() are called. And I want to log 
remove() calls the way we currently log get() and set().

So one solution is to define remove() and clear() in CHI/Driver.pm, and have 
them call _remove() and _clear() in the driver subclasses.  But this kind of 
change makes me uneasy for several reasons:

* It changes the driver API, i.e. all existing drivers out there have to 
modified. And we might have to change it again as we identify new methods to 
wrap.

* The list of 'normal' versus 'underscore' methods becomes rather arbitrary - 
it's "whatever we've needed to wrap so far".

Moose has before & after modifiers, but can they be defined in the superclass 
and affect the subclass??

I guess CHI.pm could use a wrapping module, like Sub::Prepend or Hook::LexWrap, 
on any driver class the first time it is used, e.g. the first time someone says

CHI->new(driver => 'File')

we wrap the appropriate File methods. But this feels hacky - these tools seem 
like a way to modify someone else's module, not as a standard part of your own 
class.

Advice appreciated!

Thanks
Jon

I may not be grasping the exact problem, but I wonder if CHI::Driver shouldn't 
be a role instead.  Then you could require a method and add a wrapper as well.  
Lately I've been thinking unless the class is going to be instantiated it 
should be a role.  I'm not so down on base classes anymore.  Not sure if that 
helps. 

John


  

Re: MooseX::Types : subtype/coerce not found in Roles (hand_optimized_type_constraint?)

[John Napiorkowski]

Hey, based on your dumps, I'm not sure you are on the latest MX:Types and all.  
Could you check that so that I can start to look through this and see if there 
are any bugs I can create a test case out of?  Thanks!

john



- Original Message 
From: Stevan Little 
To: i...@sillit.com
Cc: moose@perl.org
Sent: Thursday, January 29, 2009 1:13:03 PM
Subject: Re: MooseX::Types : subtype/coerce not found in Roles  
(hand_optimized_type_constraint?)

I tend to do the following:

- make a MyApp::Types package that handles *all* custom type  
definitions and type coercions
- make all other packages load MyApp::Types (even if they dont need  
it, because their deps might need it)

Then as far as circular refs are concerned, they are tricky and each  
case is a little different. The key is to map out what you need and  
the force things to load in that order (this is where the global  
MyApp::Types can be really handy).

Also, find_type_constraint is your friend, it is exported from  
Moose::Util::TypeConstraints and can basically be used to detect if  
the type already exists or not. Something like:

if (find_type_constraint('Foo')) {
 # do something wiht the Foo type here, like add a coercion
}

Of course the ideal situation is that you break your circular refs  
instead, but sometimes that is just not possible.

- Stevan

On Jan 29, 2009, at 11:59 AM, i...@sillit.com wrote:

> Stevan,
>
> Many thanks for getting back so quickly - that sounds exactly the sort
> of thing that must be happening.
>
> Before I dive in - could I ask what the recommended best practice for
> avoiding circular "use" cases is (if any)? I've generally tried to
> "use" all the modules required by the package to keep each package as
> independent as possible without loading everything unneccessarily. Or
> am I missing something?
>
> Cheers
>
> Ian
>
> On 29/01/2009, Stevan Little  wrote:
>> Ian,
>>
>> Types can sometimes be very sensitive to load order since they are
>> really done at runtime (it is the runtime immediately following
>> compile time, but still runtime). Based on your description I think
>> you are getting bitten by the auto-creation of types (if Moose  
>> doesn't
>> know the type it makes it into a Object subtype that isa(> type>)).
>>
>> I would check to make sure that you do not have any circular
>> dependencies in how you load your modules, Perl will handle these
>> fine, but Moose types will be sensitive to the order in which the
>> circle is traversed.
>>
>> - Stevan
>>
>> On Jan 29, 2009, at 6:54 AM, Ian Sillitoe wrote:
>>
>>> Hello,
>>>
>>> I have a problem with subtype/coercions (MooseX::Types library) that
>>> I've
>>> spent ages trying to understand, then ages trying abstract into a
>>> simple
>>> test case but all simple cases seem to work as expected but just not
>>> in my
>>> larger code base. I was hoping that if I put the symptoms up someone
>>> may
>>> spot what is going on and put me out of my misery (or at least point
>>> me to
>>> where I should continue my digging).
>>>
>>> Please excuse any typos in the (incomplete) example code below. I
>>> have coded
>>> up a full version of this simple scenario and I can't replicate the
>>> error
>>> I'm getting in my real code base anyway - so this is meant purely  
>>> for
>>> illustration.
>>>
>>> # Types library
>>> package My::Types;
>>> use Moose;
>>> use MooseX::Types -declare [qw( Version DomainID )];
>>> use My::Version;
>>>
>>> subtype 'Version',
>>>   as 'Object',
>>>   where { $_->isa( 'My::Version' ) };
>>>
>>> coerce 'Version',
>>>   from 'Str',
>>>   via { My::Version::init_from_string( $_ ) };
>>>
>>> subtype 'ObjectID',
>>>   as 'Str';
>>>
>>> # Role to associate versions with objects
>>> package My::Role::Verisoned;
>>> use Moose::Role;
>>> use My::Types qw(Version);
>>> has 'version' => (is => 'rw', isa => 'Version', coerce => 1);
>>>
>>> # Versioned Object1
>>> package My::Object1;
>>> use Moose;
>>> with 'My::Role::Versioned';
>>>
>>> # Versioned Object2
>>> package My::Object2;
>>> use Moose;
>>> use My::Types qw( DomainID );
>>> use My::Object1;
>>> with 'My::Role::Versioned';
>>>
>>> has 'domain_id' => ( is => 'rw', isa => 'DomainID' );
>>>
>>> sub get_object1 {
>>>   my $self = shift;
>>>   return My::Object1->new( version => $self->version );
>>> }
>>>
>>> In this simple case, the subtype/coerce works as expected in both
>>> objects
>>> (the type constaint of the 'version' attribute is the identical)
>>>
>>> $o2 = My::Object2->new( version => '3.2' );
>>> $o1 = $o2->get_object1;
>>>
>>> warn "Object1: " .
>>> My::Object1->meta->get_attribute_map->{version}->{type_constraint}-
 dump;
>>> warn "Object2: " .
>>> My::Object2->meta->get_attribute_map->{version}->{type_constraint}-
 dump;
>>>
>>> Object1: $VAR1 = bless( {
>>>   'compiled_type_constraint' => 'CODE(0xa41e310)',
>>>   'parent' => 'My::Version',
>>>   'coercion' =>
>>> 'Moose::Meta::TypeCoercion=HASH(0xa991c70)',
>>>   

RE: Possible to use coerce and auto_deref?

[John Napiorkowski]

--- On Thu, 1/15/09, Howe, Tom (IT)  wrote:

> From: Howe, Tom (IT) 
> 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)
> >  wrote:
> >
> > > From: Howe, Tom (IT)
> 
> > > Subject: Possible to use coerce and auto_deref?
> > > To: "Sartak" 
> > > Cc: ch...@prather.org, "Yuval Kogman"
> ,
> > > "Stevan Little"
> , 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 an

Re: Possible to use coerce and auto_deref?

[John Napiorkowski]

--- On Wed, 1/14/09, Howe, Tom (IT)  wrote:

> From: Howe, Tom (IT) 
> Subject: Possible to use coerce and auto_deref?
> To: "Sartak" 
> Cc: ch...@prather.org, "Yuval Kogman" , "Stevan 
> Little" , 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 { [] },
> };
> 
> 
> 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)
> >  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.


  

Re: How can I best showcase Moose at a conference talk?

[John Napiorkowski]

--- On Wed, 1/7/09, Paul Fenwick  wrote:

> From: Paul Fenwick 
> Subject: How can I best showcase Moose at a conference talk?
> To: moose@perl.org
> Date: Wednesday, January 7, 2009, 9:31 PM
> G'day Moosers,
> 
> I'm giving at talk at http://linux.conf.au/ in two
> weeks time on cool things
> that people may have missed in Perl.  I'm expecting an
> audience of somewhere
> between 100-300 people, most of whom I don't expect
> will have only minimal
> Perl experience.
> 
> One of the many technologies I'll be talking about is
> Moose, and my main
> goal in showing it is to try and dispel the myth that Perl
> has to be ugly,
> and that Object Oriented Perl has to be a pain in the arse.
> 
> With that in mind, is there anything in particular that I
> should be showing
> off but which I may have missed?  Feel free to suggest the
> obvious here, but
> be aware that anything I show off needs to be accessible to
> "end users" of
> the language, and I won't be able to go into anything
> in too much depth.
> 
> Caelum and gphat on #moose have already mentioned
> MooseX::Method::Signatures
> and MooseX::Declare, both of which provide a shinier
> interface, and hence
> suit my goals nicely.
> 
> Cheerio,
> 
>   Paul

You might want to look at the "Unsweetened.pod" stuff, which really shows you 
all the boilerplate and lifting that Moose is doing for you.  That's provided a 
great "Ah ha" moment for a few people I only had a few minutes with.

I'd also humbly plug MooseX::Types::Structured, which although is a Moose types 
extension (not core Moose) gives you really neat abilities to describe your 
type constraints and with recent updates to MooseX::Types even allows recursive 
type constraints.  I'd also say it's a great example indicating growth and 
diversity within the Moose software 'ecosystem'.  I believe that Moose promotes 
an unprecedented level of knowledge sharing and accommodation among an 
expanding group of like minded authors, promoting sensible standards without 
unduly trampling the Perl individualist philosophy.  "More than one way to do 
it" promotes a healthy competition, but can sometimes lead to extremely 
fragmented and unconnected development.  Moose type constraints is a perfect 
example of this.  How many CPAN distributions are floating around that offer 
some type of argument validation?  In the absence of a community and a sensible 
framework most gathered little mindshare and
 even less patches and commits.  So I think all the MooseX stuff as well as how 
core Moose has integrated new developers is a sign of amazing success.  I would 
say that Moose is a great framework as well as a major win for the Perl 
community.

John (jnapiorkowski)


  

Re: MooseX::DBIc

[John Napiorkowski]

--- On Tue, 12/30/08, Stevan Little  wrote:

> From: Stevan Little 
> Subject: Re: MooseX::DBIc
> To: "Sean Allen" 
> Cc: moose@perl.org
> Date: Tuesday, December 30, 2008, 9:29 PM
> Sean,
> 
> Take a look at the test suite, specifically the code inside
> https://svn.iinteractive.com/repos/cpan/MooseX-DBIC/trunk/t/lib/
> that is the most complete example we have (other then $work
> code which I can't show you).
> 
> Keep in mind though that this module is unreleased and only
> been used in one (fairly straightforward) $work application
> so far. In other words, this is unreleased pre-alpha
> software, use at your own risk. Chris Prather (perigrin on
> IRC) can speak to this better then I can as he was the
> author of the $work app.
> 
> That all said, it is a pretty simple wrapper and I suspect
> it doesn't have too many bugs lurking below the surface
> as it is very shallow. And if you really would like to see
> it released and more stable I would be happy to give you a
> commit-bit and you can start writing more tests, docs, etc.

I'd also add that as we begin to close off the development of DBIC .08100 and 
begin contemplating .09, that's going to be a Moose inspired rewrite so if you 
are very interested and have time you should start hanging out on #dbix-class

--john

> 
> - Stevan
> 
> On Dec 30, 2008, at 12:11 PM, Sean Allen wrote:
> 
> > I'm rather new to Moose ( 3 days in ) and if
> I'm going to make use of it, then the DBIc extension
> looks like a must have for me.
> > I found it via google and have looked over the code in
> svn but I'm not proficient with Moose so I don't
> really understand how
> > I would go about using it. Is there any example code
> floating around I could take a look at?
> >


  

Re: ![PATCH] Moose::Util

[John Napiorkowski]

--- On Fri, 10/24/08, Ovid <[EMAIL PROTECTED]> wrote:

> From: Ovid <[EMAIL PROTECTED]>
> Subject: ![PATCH] Moose::Util
> To: moose@perl.org
> Date: Friday, October 24, 2008, 8:50 AM
> Hi folks,
> 
> I didn't attach a patch for Moose::Util.  I pasted it. 
> That's because you shouldn't apply it, but we (BBC)
> have to as a temporary fix until we can understand exactly
> what's going on and how to better fix this.
> 
> Basically, the patch changes
> &Moose::Util::resolve_metaclass_alias to actually use
> *our* metaclass name if it contains the string
> 'Pips3'.  This more than *doubles* the speed of our
> test suite.  However, 'Pips3' probably isn't
> terribly useful for most folks :)

Is the problem that Moose is underperforming for you, or is there a test case 
we can try to make it fail?

> 
> We tried to do this:
> 
> if ($metaclass_name !~ /^Moose/) {
> 
> But our test suite fell down and went BOOM!

I'll have to let someone else comment on this, but I would imagine somehow this 
is always getting called.  Problem not worth trying to debug this bit.

> 
> This is deeply mysterious to us, so if anyone can offer
> insight into this, we'd be grateful.
> 
> Cheers,
> Ovid
> --
> Buy the book -
> http://www.oreilly.com/catalog/perlhks/
> Tech blog- http://use.perl.org/~Ovid/journal/
> Twitter  - http://twitter.com/OvidPerl
> Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
> 
> ===
> --- Util.pm (revision 11775)
> +++ Util.pm (working copy)
> @@ -126,9 +126,17 @@
>  sub resolve_metaclass_alias {
>  my ( $type, $metaclass_name, %options ) = @_;
>  
> +
> +
>  if ( my $resolved = eval {
> -my $possible_full_name = 'Moose::Meta::' .
> $type . '::Custom::' . ( $options{trait} ?
> "Trait::" : "" ) . $metaclass_name;
> +my $possible_full_name;
>  
> +if ($metaclass_name =~ /Pips3/) {
> +   $possible_full_name = $metaclass_name;
> +} else {
> +
> +   $possible_full_name = 'Moose::Meta::' .
> $type . '::Custom::' . ( $options{trait} ?
> "Trait::" : "" ) . $metaclass_name;
> +}
>  Class::MOP::load_class($possible_full_name);
>  
> 
> $possible_full_name->can('register_implementation')


  

Re: RCF for option enhanced type constraints

[John Napiorkowski]

me=>Str, age=>Int, HashRef]

which is supposed to match: [$obj, name=>John, age=>39, \%opts]

Right now the Tuple constraint in MooseX::Types::Structured can't support this 
since each constraint in the structure is stand alone.  What I need is a sort 
of 'next' statement in type constraints.  That way I can do something like 
(totally contrived syntax):

Tuple[Object[next=>Dict[name=>Str, age=>Int, {next=>HashRef}]]]

That would work and we could probably make something like:

Chained[Int,  Dict[name=>Str, age=>Int], HashRef]

To make the syntax cleaner.  I guess we'd also like:

Merged[Dict[name=>Str, age=>Int],Dict[friends=>Object]]

Duncan, I had a few questions specifically to your comments:

> Precision
> Scale

These have a problem of being, on the face of it, radix-specific.  You
should generalize those into versions that also have radix parameters,
where 2 and 10 are likely the most common values; or maybe you already had
a radix parameter in mind.

So I added a Base hint for Num.  The intended usage is something like:

subtype as Num[Base=>10, Precision=>xxx, Scale=>yyy]

With the goal of constraining a number.  I lifted this from the SQL types.  Let 
me know if you think I am understanding your comment correctly.


So, would like thoughts on all the above and any review of the updated sketch 
in the repository would be appreciated.  

Repository Link: 
http://code2.0beta.co.uk/moose/svnweb/index.cgi/moose/browse/MooseX-Types-Dependent/


Sincerely,
John Napiorkowski

RCF for option enhanced type constraints

[John Napiorkowski]

o what is missing?  Do we want to 
add more types, like for URIs, or fixed types like ZERO, INFINITY, etc.  
Declare-Constraints-Simple has some neat features for aggregating constraints 
(And, Or, Not, Xor, ect.)  We have Union, which covers Or, but maybe we'd like 
more.  Is there stuff here you think doesn't belong?  Does it belong in a 
separate project, or just doesn't belong period?  What other existing type 
constraints libraries might benefit from this approach?  For example, I've done 
a bit of work on MooseX::Types::DateTime[X] and was thinking this could be used 
to hint stuff like TimeZone information (ie isa=>DateTime[TZ=>'USA/Eastern'] 
and similar).

I know this is a lot to review, but I should be on IRC often for discussion.

Sincerely,
John Napiorkowski


  

Re: Moose::Meta::Role::rename_attribute

[John Napiorkowski]

--- On Wed, 9/24/08, Christopher Brown <[EMAIL PROTECTED]> wrote:

> From: Christopher Brown <[EMAIL PROTECTED]>
> Subject: Moose::Meta::Role::rename_attribute
> To: moose@perl.org
> Date: Wednesday, September 24, 2008, 8:50 PM
> Hi All,
> 
> Decided to ask this one of the list rather than #Moose.
> 
> Is there / should there be a
> *Moose::Meta::Role->rename_attribute* method?
> It is easy to change the guts of an attribute using the
> *has "+"  *syntax,
> but I have not found an official way to change the name of
> an attribute.   I
> am wondering if Moose::Meta::Role should contain a
> rename_attribute method
> that does something like the following:
> 
> my ( $self, $old_name, $new_name ) = @_ ;
> 
> my $attr = $self->meta->get_attribute(
> $old_name );
> $self->add_attribute( $new_name, $attr );
> $self->remove_attribute( $old_name );
> 
> Thoughts,
> 
> Chris

Chris,

To be honest I don't think this should be a function of Role, since in my mind 
I see a Role as being something that defines a package of behavior, and it 
really should not be mucking about with the attributes or methods of a class 
that consumes it, unless via one of the clearly established means, such as the 
advice modifiers around, before, etc., and in which case any so modified 
methods should required. 

So I think that doing this could well be improper separation of concerns.  I 
guess something like this could have some use as a utility class.

--John Napiorkowski



  

Re: Multiple coercions ?

[John Napiorkowski]

--- On Wed, 9/24/08, John Napiorkowski <[EMAIL PROTECTED]> wrote:

> From: John Napiorkowski <[EMAIL PROTECTED]>
> Subject: Re: Multiple coercions ?
> To: "Charles Alderman" <[EMAIL PROTECTED]>
> Date: Wednesday, September 24, 2008, 12:00 PM
> --- On Wed, 9/24/08, Charles Alderman
> <[EMAIL PROTECTED]> wrote:
> 
> > From: Charles Alderman
> <[EMAIL PROTECTED]>
> > Subject: Re: Multiple coercions ?
> > To: moose@perl.org
> > Date: Wednesday, September 24, 2008, 11:34 AM
> > Meta questions:
> > 
> > Is the purpose of this list to only report bugs or
> discuss
> > design  
> > questions?  Or is it to help out Moose users?  Should
> the
> > list be  
> > split into moose-dev and moose-users?
> > 
> > Perhaps if a user happens to overlook the version
> > they're running  
> > before asking a question, it could be accepted as a
> newbie
> > question in  
> > a moose-users list conversation.
> > 
> > Thanks,
> > Charles Alderman

Right now we have IRC channels split this way.  To be
honest, the IRC gets a lot more traffic than the mailing
list in terms of discussion and help.  This makes sense to
me since Moose is rapidly growing and also I've noticed
that for Perl there have been a preference to IRC over
mailing lists and other types of dicussion (blogging, etc). 
There is a good part to this, since IRC is immediate, but of
course there is a downside since IRC is very unstructured
and it's not searched by the big search engines, which I
think hurts us PR wise.

Try irc://irc.perl.org#moose for general moose questions
and irc://irc.perl.org#moose-dev for moose new development.

Peace

John Napiorkowski

> > 
> > - Original Message -
> > From: Dave Rolsky <[EMAIL PROTECTED]>
> > Sent: Wed, 24 Sep 2008 10:14:49 -0500 (CDT)
> > Re: Re: Multiple coercions ?
> > 
> > > Ok, Moose _0.58_ was just released, and
> you're
> > reporting bugs in 0.31,
> > > which was released approximately 10 months ago?
> > >
> > > Why?
> > >
> > >
> > > -dave
> > >
> > > /*==
> > > VegGuide.Org
> > > Your guide to all that's veg
> > > ==*/


  

Re: how to handle error with type constraint

[John Napiorkowski]

--- On Mon, 9/22/08, vincent roudil <[EMAIL PROTECTED]> wrote:

> From: vincent roudil <[EMAIL PROTECTED]>
> Subject: how to handle error with type constraint
> To: moose@perl.org
> Date: Monday, September 22, 2008, 9:40 AM
> Hello Moose,
> I am just starting to explore Moose. This is probably
> something simple, but
> I can't figure out the best way to do this.
> 
> With the Moose type constraint, I would like to get control
> of the error
> handling when the type is invalid.
> 
> Here is an example.
> 
> a class host, with 2 attributes, name and ip_addr, with a
> control on the IP
> address validity:
> # package host.pm
> package host;
> use Moose;
> use Moose::Util::TypeConstraints;
> 
> use Regexp::Common qw /net/;
> subtype IPAddr
> => as Str
> => where {/^$RE{net}{IPv4}$/}
>  => message { 'invalid IP address'};
> 
> has 'ip_addr' => (isa => 'IPAddr', is
> => 'ro', required => 1);
> has 'name' => (isa => 'Str',  is
> => 'ro', required => 1);
> 1;
> # end package host.pm
> 
> The type constraints works fine. Only that when the IP
> address is invalid
> the program dies, with great verbosity.
> 
> I would just like when IP address is invalid, to print a
> message in a log
> file, and that the creation of the instance fails quietly,
> so I could use
> the host class like this:
> 
> # main.pl:
> use host;
> 
> my $h=host->new(name=>'jupiter',
> ip_addr=>'10.10.10.1');
> 
> if ($h) {
>  print $h->name." created successfully with the IP
> address ".$h->ip_addr;
> }
> 
> If someone could point me to the right direction, that
> would be great.
> 
> Thanks in advance.
> 
> Vincent.

Hey,

For me I would try to clearly separate my business logic validation needs from 
type constraints on my storage classes or domain model.  There are a few 
reasons for this, mostly having to do with separation of concerns and the fact 
that incoming user data will likely have a few different validation paths at 
some point.  Also you can create reuseable validation classes.

I don't know your exact problem domain, but for me as a web developer I am 
doing a lot of validation and error messaging for incoming post params.  For 
that I use Data::FormValidator, and make as many custom classes as I need.  
Then I'd try to have some sort of workflow on the incoming params to first 
validate and then if valid pass on to the domain model.  I try to see my type 
constraints as a sort of "last chance" to catch problems before they generate a 
hard error in my database.

The only downside to my method is that you end up rewriting validation code a 
few times.  I know there are new tools cropping up to help with this, Reaction 
and Ernst from what I understand are attempts to let you infer your business 
validation needs from the type constraints on your storage object, but yet 
retain enough flexibility when your business validation needs different from 
the domain constraints.  I haven't had time to play with these yet, but maybe 
someone else on the list will jump in.

Until then I recommend having user input validation as a first layer before it 
tries to hit your Moose attributes.

my $0.02

John Napiorkowski


  

Re: Moose Role Call

[John Napiorkowski]

--- Chris Prather <[EMAIL PROTECTED]> wrote:

> 
> On Jan 24, 2008, at 7:50 a, Stevan Little wrote:
> 
> >
> > On Jan 23, 2008, at 9:37 PM, Matt S Trout wrote:
> >> On Wed, Jan 23, 2008 at 06:47:53AM -0800, John
> Napiorkowski wrote:
> >>> I thought we were calling it a post modern
> object
> >>> system now?  Which for me brought on a panic
> attack,
> >>> recalling my post modern literary criticism
> class from
> >>> my grad school days.
> >>
> >> I call it "Meta object orientation and syntax
> entensions" :)
> >>
> >
> > I call it "Most Orangutans Order Szhechuan
> Entrees" :)
> >
> > I understand they like the spicy stuff.
> >
> > Although to be (kinda) serious, the post-modern
> bit is because  
> > really a "modern" OO system is something like Java
> or C#, which is  
> > (at this point) rather boring and straight
> forward. Moose aims to  
> > push past those languages, dragging along with it
> things from CLOS,  
> > BETA, Smalltalk, Perl 6, etc. It builds upon the
> "modern" OO  
> > systems, and looks for the next step, hence the
> "post".
> >
> > Also, Post-modern (at least in the fine-art world)
> tends to include  
> > a lot of appropriation and recontextualization
> (see Pop-art, Neo- 
> > Dadaism, the painting revival in the 80s, etc).
> Moose steals stuff  
> > from many other languages (appropriation) and
> attempts to put it  
> > into a perl-ish context (recontextualization), so
> in that sense  
> > also I see it as post-modern.
> >
> > And lastly, post-modernism tends to be a lot more
> fun and less  
> > stuffy then modernism :)
> 
> Also from a Lit Crit view point, post modernism has
> a lot to do with  
> the power of the reader for informing half the value
> of the story.  
> This is very literal in Moose with the deep
> introspection and ability  
> to interact with and override the metaobject
> protocol. I could  
> probably have a long digression about method
> modifiers (around/before/ 
> after) being meta-narrative constructs which break
> the fourth-wall of  
> programming by talking about the methods they are
> modifying ... but  
> really that won't happen until Perl gets macros.
> 
> -chris

Hmm, but another part of post modernism is the concept
that the object isn't really there, that all we have
is the representation.  Which works for me because I'm
still weak on understanding the metafu, but trying to
get there.

-john

> 



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: Moose Role Call

[John Napiorkowski]

--- Matt S Trout <[EMAIL PROTECTED]> wrote:

> On Tue, Jan 22, 2008 at 08:37:19PM -0500, Robert
> Hicks wrote:
> > Stevan Little wrote:
> > >Anyone on the list other than me and Yuval?
> > >
> > >- Stevan
> > >
> > 
> > I am.
> > 
> > Just saw the latest release notes. Very cool. I am
> looking over some 
> > presentations from
> http://www.iinteractive.com/moose/ at the moment to 
> > get a feel for the "framework".
> 
> Please don't call it a framework, it's an object
> system. The word framework
> is so badly overloaded these days it'll just confuse
> people (what you
> call it in your head is up to you, but in the name
> of good advocacy it'd
> be better not to call it that out loud :)
> 

I thought we were calling it a post modern object
system now?  Which for me brought on a panic attack,
recalling my post modern literary criticism class from
my grad school days.

--john


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

test case for trouble inheriting overload behavior with roles

[John Napiorkowski]

Hi,

Recently I was building a Role that used the overload
module to manage some simple stringify behavior when I
noticed that classes which consumed the role didn't
seem to get the overload behavior.

As discussed on the IRC chat yesterday (from my
timezone at least) I've build a test case for this,
which is attached.

Basically the test case shows how overload works for
inheritance with plain old perl objects, moose
objects, but not for moose objects which do a role.

I'm guessing that this would be an issue for other
modules that work similarly to overload, in that they
create stuff in import that is on the caller
namespace.  So this problem might bite others at weird
times.

If anyone more familiar with how Roles do their job
could take a look at the test case and let me know
what they think I would appreciate it.  I'm happy to
work on this as well, just need a little mentoring
about where to start.

Thanks!

John Napiorkowski


   

Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

roles_overload.tar.gz
Description: 3273028528-roles_overload.tar.gz