Re: MooseX::OmniTrigger
Can you elaborate on these bugs? It's not a bug, but the default trigger and intializer behavior were supremely awkward. In no case thus far have I found it to be what I wanted. I wrote about this back in 08'. I don't think any non-core dev that has the grid memorized. http://en.wikibooks.org/wiki/Programming_with_Moose/Syntax/has#Clearing_up_confusion -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: Infinity Interactive Is Hiring
Infinity Interactive (the birthplace of Moose) is hiring! We have an exciting and interesting Perl project happening and we need programmers who understand not only Modern Perl (Moose, Catalyst, DBIx::Class, Bread::Board and more) but also modern web development (REST web-services, client-side MVC, YUI, HTML 5, etc) and NoSQL database technologies (MongoDB specifically, but document oriented DBs in general, accompanied by interesting stuff like ElasticSearch). Excellent, where do I send my application? I have experience with all that stuff except Bread::Board. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
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.
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
Role composition and BUILD {}
Because a role doesn't have a BUILD people often write `around 'BUILD'
= sub {}`. If this is to continue, should BUILD be special cased such
that a role wrapping it can still fire code if it isn't present in the
composing class? Should the role install BUILD if it isn't present,
like an `override_or_after 'BUILD' = sub {}`?
I've just got an Attribute Trait which I want to set from within in a
role, I do that currently by wrapping BUILD.
--
Evan Carroll - e...@dealermade.com
System Lord of the Internets - Dealermade
web: http://www.dealermade.com
ph: 888.403.9143
Re: Role composition and BUILD {}
11:14 @mst sub BUILD {} after BUILD = sub {
Amusing...
sub BUILD {'amusing hack'}; after 'BUILD' = sub {}
it is.
--
Evan Carroll - e...@dealermade.com
System Lord of the Internets - Dealermade
web: http://www.dealermade.com
ph: 888.403.9143
Why is native attribute traits defaults depr
Why is native attribute trait defaults deprecated? Is there is a
technical reason for this? So now we have to explicitly provide a u
Allowing a native trait to automatically supply a default is
deprecated. You can avoid this warning by supply a default, builder,
or making the attribute required at
/usr/local/share/perl/5.10.1/DM/Model/Vehicle.pm line 26
Line 26 doesn't even have a default (line 26 starts my stock declaration)
has 'stock' = (
is = 'rw'
, isa = StockNo | Undef
, coerce = 1
, traits = ['String']
, handles = { 'include_in_exports' = 'append' }
);
The next line after it does my image declaration, it has a default but
no native trait.
has 'images' = ( is = 'rw', isa = 'ArrayRef[URI]', default = sub {
[] }, auto_deref = 1 );
What's going on? Moose version 1.17
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
Re: Why is native attribute traits defaults depr
That's what the warning is about. You don't provide a default so the String native delegation trait provides a default for you (an empty string). This is actually a really good replace. It makes total sense and it was my inability to read and otherwise perfectly clear error that caused my confusion. Overall, it was too much magic for no particular gain. Good decision, and easy fix. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Why is initializer going away?
I personally use initializer a lot in my Moose code, yet I hear a lot of people saying negative things about it? What's wrong initializer and is it going away? I often find its hook-choice more useful than trigger. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: [TEST CASE] Constructor provided arguments and strict-default fire ordering is confusing or buggy.
This is not a bug. Attribute initialization order is explicitly
undefined (the documentation mentions this in several places). If you
need a defined initialization order, you should make the appropriate
attributes lazy.
That's not how I read that statement. When you say attribute
initialization order is undefined I read that literally. Example,
has foo = ( isa = Int, is = ro, default = 1 );
has bar = ( isa = Int, is = ro, default = 2 );
Is undefined such that foo, and bar will be set in an undefined
order. Not, that the constructor provided arguments and
strict-defaults are undefined. I don't even read initialization as
being an apt choice of words for setting foo, via
Class-new({ foo = bar })
I'm not sure if this misunderstanding is unique to myself or not, but
I didn't take your statement (or the docs) to be at odds with my own
mental model of Moose behavior.
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
Re: [TEST CASE] Constructor provided arguments and strict-default fire ordering is confusing or buggy.
Also, I have no idea what your parenthetical means.
Parenthetical indicate that I know default fires before the
initializer for the attribute, but that not all defaults for all
attributes will fire before any of the initializers. Currently, an
Attribute process not a class process.
Awkward and counter-intuitive is very subjective and therefore not a
compelling reason to change things; for example, people regularly seem to
think
that it is awkward and counter-intuitive not to override new() when coming
from
vanilla Perl 5 OO.
In this particular case, the way Moose does things means that code related to
a
given attribute (default, etc.) only sees that particular attribute in a
half-built state -- that is, each other attribute is either completely
initialized or not at all. This means there's much less opportunity for your
object to be exposed in an inconsistent state.
I don't see the logic in the term inconsistent. I've showed the flow
defined in a sequential list in my original post, maybe you can
clarify why you feel such a flow is inconsistent. I'll go ahead and
show you what I wanted to do with this. I have a Class, it should
accept either a company_id, or a hash of attributes if you provide
a company_id the attribute hash is lazy when it is needed. If you
provide a hash of company attributes, then the value is immediately
entered into the DB, and the company_id gets set appropriately:
has 'attr' = (
isa = 'HashRef'
, is = 'ro'
, lazy= 1
, predicate = '_has_attr'
, default = sub {
my $self = shift;
die No company id unless $self-_has_company;
# Get from db.
}
);
has 'company' = (
isa = 'Int'
, is = 'ro'
, predicate = '_has_company'
, default = sub {
my $self = shift;
die 'No attributes or company id' unless $self-_has_attr;
# Insert into DB
}
)
Anyway, it just seems very naturally that this should work. You're
explicitly providing non-defaults for some attributes, but they're
order is undefined until other attribute's get their defaults -- it
seems like the current method provides no gain whatsoever.
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
Re: Overhead of using MooseX::Declare
Files=11, Tests=31, 44 wallclock secs ( 0.22 usr 0.05 sys + 39.28 cusr 1.48 csys = 41.03 CPU) Result: PASS You're using /usr/bin/time, that makes this the most useless benchmark in the history of mailing lists everywhere. You're not even testing one thing, you're testing eleven (t/001*-t/0010* + t/99*) that presumably all have `use Moose`. You're unrevealing statement is akin to this, MooseX::Declare has high startup costs. And, that's why the trend wagon still makes frequent stops at Mouse.pm, and the 3 year old idle project MooseX::Compile still gets talked about as an upcoming fix. (28-2) / 11.0 2.3636363636363638 Seriously, MooseX::Declare adding less than 2.36 seconds to start up on an old machine.. That's the post.. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: Overhead of using MooseX::Declare
I'm sorry, where is the benchmark? Does it use the type system? Coercions? Method signatures? I didn't see it in the attached links and I feel without it this is a rather bad post... Does your use of the term run include startup costs? Or, is this a runtime benchmark? -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: [ANNOUNCE] Frost version 0.70
Frost version 0.70 is out. q[Modules with descriptions written in prose]-- q[Modules with packages names in prose]-- Seriously, CPAN is not dungeons and dragons. Quit it. Frost.pm reads like a butchered revision of Finnegans Wake. * Data::Dumper provides configuration that doesn't involving borking other uses of Data::Dumper, it forces you into the OO paradigm: use it: http://search.cpan.org/~smueller/Data-Dumper-2.128/Dumper.pm#Configuration_Variables_or_Methods * Don't use prototypes, unless you need prototypes. And, if you're going to use prototypes in the code, then use the benefits in the docs: ie, not true() but true. And, don't do that. In perl 1 is true, just deal with it. And to second Dave's point: announcing a Moose based module on the lists is slightly annoying. Publishing that public support for your module is provided on the lists is erring on the obnoxious bank of River Obnoxious. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: deprecating (part of) lazy_build
1) reuse 'builder', i.e. 'builder = 1' is special cased to be the same as 'builder = _build_$attr' Someone said what about subs named '1'? but I think we're probably all OK with ignoring anyone crazy enough to do that. I made this suggestion, *years* ago (even providing a patch for it iirc). Stevan rejected it because he was uncomfortable with the attribute taking both String, and Bool. It was always his position to have has($_, isa = Str, is = ro, predicate=has_$_) for qw/ foo bar baz/; And the like. Again, I think this is a great idea, but it will never happen. I could even see it going one step further and to make a special token for this. use MooseX::Autoname qw(generate_by_name); has foo = ( isa = Str , is = rw , predicate = generate_by_name , builder = generate_by_name ); Or, something. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Ping about Traits and List::Util stuff on Array
I have two questions:
* Should the Array trait using List::Util permit regexes? i.e.
perl -MList::Util -wE'use List::Util qw/first/; say first {/foo/}
qw/bar foo bazko bazfoo/'
package Class;
use Moose;
has foo = ( isa = ArrayRef, is = rw, traits = ['Array'],
handles = { first_foo = foo } )
Class-new(foo=[qw/foo bar baz quz/])-first_foo(qr/foo/);
* Regarding the new 1.15 in git, why does the new
Moose::Meta::Method::Accessor::Native::*, stuff use string eval? What
was wrong with the old approach.
Native Trait delegations are now all generated as inline code. This should
be much faster than the previous method of delegation. In the best case,
native trait methods will be very highly optimized.
How is string eval generation better? I mean is the end goal just to
shave a function-call at the expense of turning Moose into
perl-pre-processor written in perl? Wouldn't this code be better in
List::Util? Why should Moose have the sanitation features here? I'd be
more interested in reading more about this optimization. I've never
seen any code on CPAN do it.
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
Re: Roles on the CPAN
with ::Role:: being in the middle of the name, rather than at the beginning or at the end. Again, I'm not sure this answers anything at all. Would it make more sense to put ::Moose:: in the package name of classes that used Moose internally? If no, why? What is your opinion if someone creates a WiX3::XML::Tag that is non-Role Moose class. I'm just not sure why people want this. If people want to shop for roles that they can use to enhance their Moose classes, why not just add the functionality into search.cpan, or Meta.yml. ... What if the Role is some how fundamentally more often useful as a Trait? Should it be published as WiX3::XML::Trait::Tag. it just seems like we're using package names to store random crap about the module that has nothing to do with the *name* of the module and is much better inferred and indexed on the content of the module. Being a Trait has very little to do with the *function* of the module. A Trait isn't all that far from any other module that uses SubExporter for method-install. Should we give those a separate namespace? -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: Defining attributes
but the following one doesn't:
has $_ = (is = 'rw', isa = 'Str') for 'a' .. 'zzz';
Something about this I find especially amusing, but to drive the point
home with today's poorly worded Double Jeopardy question? What does
the following do?
package Class;
use Moose;
package main;
Class-new-has( 'foo', {isa='Str', is = 'rw'} );
And the forbidden Triple Jeopardy question? What ways can you have
prevented this with a much more simplistic failure?
/* spoiler below */
package Class;
use Moose;
# stuff;
no Moose;
package Class;
use Moose;
use namespace::clean; # cleans up all things before it
# stuff;
package Class;
use namespace::autoclean; # cleans up all things
use Moose;
# stuff;
Moose pollutes your namespace with keywords (functions), which perl
can't differentiate from real object methods (functions blessed into
the package (class)). It is just part of the object model. I only
posted this diatribe because I doubt you're using
namespace::autoclean, namespace::clean, or `no Moose`ing it, and you
really should be.
Another aside, Moose provides a `meta` that does keep track of
installed attributes, which does help you differentiate between random
crap in the package and true accessors - it even provides an API for
you to get to them, without explicitly calling them by name. This
should open up the ability for you to create attributes named after
Moose keywords that are totally inaccessible to code that doesn't
explicitly use meta.
http://search.cpan.org/~flora/Class-MOP-1.03/lib/Class/MOP/Instance.pm
--
Evan Carroll
System Lord of the Internets
Re: Defining attributes
On Tue, Jun 22, 2010 at 1:15 PM, Karen Etheridge p...@froods.org wrote: On Tue, Jun 22, 2010 at 10:48:21AM -0500, Evan Carroll wrote: And the forbidden Triple Jeopardy question? What ways can you have prevented this with a much more simplistic failure? I believe it has already been said that there will be a clearer error message added for when one attempts to use a Moose keyword. I think you misunderstood - or, I did - I think doy meant there will be a better warning for when one attempts to clobber the exported keyword with a generated attribute. Not, when one uses them. P.S., There can only be one System Lord of the Internets, but we can war over it I suppose. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Re: Coercions
I'm trying to create a Date type, and one of the coercions I wanted was from a DateTime object. I can't get it to work. I believe your problem is UTC vs floating. -from_epoch asserts the time_zone is UTC unless provided. All other calls to new are implicitly floating time_zones. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Re: Coercions
I see those tests are a waste. The deal is this then: subtype MyDate, as Object; What you need to do is subclass DateTime, and make subtype MyDate require that type, then coerce from type DateTime. -- Evan Carroll System Lord of the Internets
Re: feedback on MooseX::Worm
It seems pretty reasonable to me, but if I'm doing something totally wrong, I'd love to find out now rather than later. I think removing behaviors is slightly more criminal in general than adding them: wouldn't this be better done if the trait installed the writer sub on a read-only attribute? Should an API expose a worm attribute as a rw attribute? Or, should it be exposed as a ro attribute? -- Evan Carroll System Lord of the Internets
Re: xor attributes
On Thu, Nov 26, 2009 at 10:46 AM, Ovid publiustemp-catal...@yahoo.com wrote:
I have two attributes, 'xml' and 'xml_file' for an object. One or the other
must be supplied, but not both.
Must I validated this in BUILD or is there another way of doing this?
Well, I would use a trigger and predicate. Triggers are fired AFTER
the attribute is set in the constructor or with an explicit call to
the setter. I don't like to have BUILD unless I need it, and this will
check runtime sets too.
So you have something like
has 'foo' = (
isa = 'Int'
, is = 'rw'
, predicate = 'has_foo'
, trigger = \consistancy
);
has 'bar' = (
isa = 'Int'
, is = 'rw'
, predicate = 'has_bar'
, trigger = \consistancy
);
sub consistancy {
my $self = shift;
throw_error('OVID SAYS NO NO')
if $self-has_foo $self-has_bar
;
}
--
Evan Carroll
System Lord of the Internets
http://www.evancarroll.com
Re: Time for a rewrite
I've always liked the interaction between lazy and clear, clear resets the slot. That makes sense. The rest of it is all great. Trigger and Initializer were so confusing for me personally that I had to write specific notes about them. http://en.wikibooks.org/wiki/Programming_with_Moose/Syntax/has#Clearing_up_confusion Also, for when lazy is not enough, sometimes I want control over the initialization order within the same module. I was playing around with role yesterday and iirc correctly I found something surprising, I couldn't do. I thought that `with` specified the order so a role could define an attribute in a role, that a class could override with '+', that didn't work. (If I recall correctly). Roles also have open bugs that breaks the interface part, (requires() isn't working in the newest moose at all, forcing you to remove the pragma because it always throws an exception on moose-attributes). -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Re: Was the attribute set in the constructor?
On Tue, Nov 3, 2009 at 10:01 AM, Ovid publiustemp-catal...@yahoo.com wrote:
When parsing documents, if my code finds more than one title in a document,
it's an error because we don't know which title is needed. The user should
be able to override this in the constructor and provide their own title (this
is actually true for several attributes):
So the mechanism you're looking for is (1) if the title is not set in
the constructor and (2) if it has already been set in runtime then (3)
die. This can be accomplished easy enough, with around and a
predicate, and it will ensure consistency throughout the program and
anything that subclasses it.
has 'attribute' = ( isa = 'Str', is = 'ro', predicate = 'has_attribute' );
around 'attribute' = sub {
my ($next, $this, $key) = @_;
$self-has_attribute ? die 'exception' : $this-$next($key);
};
--
Evan Carroll
System Lord of the Internets
Re: Was the attribute set in the constructor?
This might be preferable to my suggestion if your object's methods are being
called mid-parse, rather than building up a data structure first and setting
attributes based on it after parsing is done. Even then, I think I'd rather
have a separate method than modify the accessor.
Yea that was me being a dumb ass.
has 'attribute' = ( isa = 'Str', is = 'rw', predicate = 'has_attribute' );
around 'attribute' = sub {
my ($next, $this, $key) = @_;
if ( $key ) {
$self-has_attribute ? die 'exception' : $this-$next($key);
}
else {
$this-$next
}
};
etc.,
--
Evan Carroll
System Lord of the Internets
http://www.evancarroll.com
doc bug
In the docs I see this for Moose::Meta::Attribute
## EXCERPT
get_value
set_value
eval { $point-meta-get_attribute('x')-set_value($point, 'forty-two') };
if($@) {
print Oops: $...@\n;
}
Attribute (x) does not pass the type constraint (Int) with 'forty-two'
Before setting the value, a check is made on the type constraint
of the attribute, if it has one, to see if the value passes it. If the
value fails to pass, the set operation dies with a throw_error.
Any coercion to convert values is done before checking the type constraint.
To check a value against a type constraint before setting it,
fetch the attribute instance using find_attribute_by_name in
Class::MOP::Class, fetch the type_constraint from the attribute using
type_constraint in Moose::Meta::Attribute and call check in
Moose::Meta::TypeConstraint. See Moose::Cookbook::Basics::Recipe4 for
an example.
## END
But, yet get_value doesn't seem to be working.
perl -Moose -e'has q[format_feed]= ( isa = Str, is = ro );
print Class-new-meta-get_attribute(q[format_feed])-get_value()'
You must pass a package name and it cannot be blessed at
/usr/local/lib/perl/5.10.0/Class/MOP/Class.pm line 37
Class::MOP::Class::initialize('Class::MOP::Class', '') called at
/usr/local/lib/perl/5.10.0/Class/MOP/Attribute.pm line 322
Class::MOP::Attribute::get_raw_value('Moose::Meta::Attribute=HASH(0x91c8310)',
undef) called at /usr/local/lib/perl/5.10.0/Class/MOP/Attribute.pm
line 309
Class::MOP::Attribute::get_value('Moose::Meta::Attribute=HASH(0x91c8310)',
undef) called at /usr/local/share/perl/5.10.0/Moose/Meta/Attribute.pm
line 562
Moose::Meta::Attribute::get_value('Moose::Meta::Attribute=HASH(0x91c8310)')
called at -e line 3
I guess it is using Class::MOP::Attribute's get_value which requires a
class name. This is odd, I just want to read from the sucker, in the
source of Mooose::Meta::Attribute I see this return
$self-SUPER::get_value($instance) which seems to imply the instance
is being set, but it isn't working. Any ideas?
--
Evan Carroll
System Lord of the Internets
http://www.evancarroll.com
Re: Ease of tracking down bugs.
I was getting a constraint violation that appeared to come out of nowhere.
It wasn't anywhere that was attempting to set the attribute or call a
constructor.
I couldn't tell where the error was coming from because the Moose error
system doesn't include the complete stack.
That kind of sounds crazy.
By making throw_error() confess() I was able to get the complete stack and
tell that what was going wrong was that the attribute's value builder was
returning undef.
throw_error currently confesses, check Moose.pm
use Carp 'confess';
..
sub throw_error {
# FIXME This
shift;
goto \confess
}
Furthermore, all sane people rely on Devel::SimpleTrace which makes
any warning or die dump the stack. I believe some of the mop and moose
set the stack level for Carp internally, and there might a problem
with that. I still interested in your problem: your example doesn't
demonstrate anything.
--
Evan Carroll
System Lord of the Internets
http://www.evancarroll.com
Re: Ease of tracking down bugs.
Have to agree with Evan here, without a reproduce-able example we can't turn it into a test and possibly fix it :) The always agreeable Evan. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Re: Meta::Attribute::Native::Trait vs MooseX::AttributeHelpers
It is hard to have these discussions being banned from IRC, but maybe - beyond a notice in MX:AH deprecation - some functionality notifying the user of an API change is required? Like something in MX:AH that when used with a Moose .90 the attribute traits would output a nice warning message. Warning the functionality of MooseX::AttributeHelpers has been moved to core, please reference Moose::Meta::Attribute::Native for the new API. I've often thought that warnings were better explicit and overly verbose in libraries and disabled via -X by the end user, but maybe an env DEVELOPMENT flag would be just as useful. There are at least a few examples of where as a developer I was stung with stuff that was currently supported but deprecated, supported but retarded, or implemented but unsupported. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
