On Wed, Sep 21, 2011 at 5:28 AM, ian.doche...@nomura.com wrote:
Does FSA::MooseRole satisfy everyone (or no-one)?
I hate it. It seems like unnecessary noise.
If the distinguishing feature of this code is that it is a role, then
name it FSA::Role or FSA::Rules::Role or something. In that
On Wed, Sep 21, 2011 at 7:24 AM, Moritz Onken on...@netcubed.de wrote:
The question is, how would someone name his dist who wants to release a
version of FSA::Role, which uses Role::Basic as Role framework?
FSA::Role::Basic
It's a useful piece of information at that point, unlike slapping
On Wed, Sep 21, 2011 at 9:04 AM, ian.doche...@nomura.com wrote:
So you are implying that
FSA::Role::Moose
Would be acceptable to you too?
Yes, if there were some existing non-Moose FSA::Role that you needed
to distinguish your version from.
Otherwise it's pointless. Imagine if everyone
On Wed, Sep 21, 2011 at 9:20 AM, Stevan Little
stevan.lit...@iinteractive.com wrote:
I suspect that actually, that the distinguishing feature of this code is that
it is an FSA and not a Role. The fact it is a Role only means you can not
instantiate it directly and must compose it into a
On Mon, 28 Mar 2011 09:49:22 -0700, Sam Brain s...@stanford.edu wrote:
(1) Does DBIx::BuildMooseObjects seem a reasonable name, and
I don't see anything Moose-specific here. The interesting bit is the
transformation from a single-level array to a multi-level structure grouped by
specific
On Sat, 29 Jan 2011 09:23:45 +0200, Octavian Rasnita orasn...@gmail.com
wrote:
I want to use some attributes that get a default value when they are not sent
as constructor's parameters and also when they are sent as constructor
parameters but with an undef value.
Use MooseX::UndefTolerant.
On Fri, 28 Jan 2011 20:23:32 +0100, Jiří Pavlovský j...@getnet.cz wrote:
subtype 'Subject'
= as 'Str';
coerce 'Subject'
= from 'Str'
= via {
my $sanitized = sanitize_input($_);
$sanitized;
};
This will never fire. Every valid Str is already a valid Subject, so no
coercion
On Fri, 28 Jan 2011 21:29:04 +0100, Zbigniew Lukasiak zzb...@gmail.com wrote:
Are there any sane options for building Moose::Roles out of Non Moose classes?
building roles out of classes is like building tires out of cars.
Maybe you actually want a role that has an attribute that holds an
On Fri, 28 Jan 2011 22:17:24 +0100, Jiří Pavlovský j...@getnet.cz wrote:
subtype MaybeSubject = as 'Maybe[Subject]';
coerce 'MaybeSubject'
= from 'Subject'
= via {
my $sanitized =sanitize_input($_);
$sanitized;
};
This doesn't make any sense to me.
Otherwise I
On Fri, 28 Jan 2011 22:36:30 +0100, Zbigniew Lukasiak zzb...@gmail.com wrote:
I am testing here if it could be made easy to use a library with
multiple inheritance in Moose. Assuming that the additional base
classes already work in a way similar to Moose Roles.
If you want your classes to be
On Thu, 2 Dec 2010 16:22:38 -0500, eric.b...@barclayscapital.com wrote:
Caught a SIGFPE
at /home/nypntdev/iprs_perl/lib/perl5/x86_64-linux/
List/MoreUtils.pm line 29 $ = eval {...}
Shouldn't you be looking here? I'm not sure this has anything to do with Moose
at all.
hdp.
On Mon, 25 Oct 2010 15:28:26 -0500, Evan Carroll m...@evancarroll.com wrote:
I'd have assumed that the process went like this:
* BUILDARGS if any
yes
* Moose provided-new which sets the attributes to the values in the hashref
* The default/initializer stage (undefined for the class, defined
On Mon, 25 Oct 2010 16:23:45 -0500, Evan Carroll m...@evancarroll.com wrote:
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
We don't like the fact that lazy_build autogenerates public clear_$attr and
has_$attr methods for you. OK, I can get behind that; those often don't belong
as part of the public API, and yes, people will consider them public if they
don't have a leading underscore, even if they aren't documented.
On Tue, 14 Sep 2010 20:45:55 +0900, Fuji, Goro g.psy...@gmail.com wrote:
Here is a RT ticket to Mouse:
https://rt.cpan.org/Public/Bug/Display.html?id=61312
Applying roles after the fact changes the flow of method modifiers. It
seems that application order takes precedence over the actual
On Tue, 27 Apr 2010 10:54:06 -0500 (CDT), Dave Rolsky auta...@urth.org wrote:
has _paragraph_name = ( is = 'ro', builder = '_build_paragraph_name' );
Then in the parent class:
sub _build_paragraph_name {
die 'This method must be overridden in the child'
}
Alternately, turn
Excerpts from Goro Fuji's message of Sun Feb 28 21:09:29 -0500 2010:
Dave said that constructor strictness should not be tied to immutability, but
I don't think so. This is because existing options to make_immutable, namely
constructor_name and inline_construcotr, etc., are irrelevant to
Excerpts from Steve's message of Fri Feb 26 09:21:05 -0500 2010:
I have a class, 'UsageDetail' which takes a CSV phone call record and
inserts it into my database. One of the attributes, 'WirelessNumber'
has dashes in it, ie: '989-555-1212'. I don't want to store the dashes
in the db.
Excerpts from Steve's message of Fri Feb 26 09:50:51 -0500 2010:
This method works great! I was very close to getting coercion to work,
but somehow my substitution returned '2' every time. Thanks all for the
help
You were doing via { s/-//g } instead of via { s/-//g; $_ }, so you were
Excerpts from Komarov Oleg's message of Sun Feb 14 18:17:07 -0500 2010:
It turns out that such an object isa 'Moose::Object', but
Moose::Object::new isn't involved in its creation.
$class-new calls $class-meta-new_object, not the other way around. You have
confused the lower level interface
Excerpts from Karen Etheridge's message of Thu Feb 04 14:09:58 -0500 2010:
As mentioned on #moose yesterday, I have found an inconsistency in the
documentation (I don't think this is a bug, as the actual behaviour looks
reasonable and correct to me):
I'm not sure whether this is a bug or not,
Excerpts from Karen Etheridge's message of Thu Feb 04 15:43:05 -0500 2010:
I'm satisfied now: there is no usecase for an initializer that couldn't
be achieved using either a trigger or by modifying the behaviour of the
attribute's setter.
This may mean that we need to make it easy to inline
Excerpts from Jesse Luehrs's message of Thu Feb 04 19:00:37 -0500 2010:
Figuring out how to do it isn't particularly obvious at the moment though.
Yeah. I mean, I've done it; it's not that much of a pain. The pain is
remembering all the places that need to be touched, let alone figuring it out
Excerpts from Ricardo Signes's message of Thu Feb 04 19:20:51 -0500 2010:
They were rjbs's baby originally, but I don't think he's actually using
them.
FWIW, I am.
LA LA LA LET'S GET RID OF INITIALIZERS
What is it that they do that can't be done any other way?
hdp.
Excerpts from Dermot's message of Tue Jan 19 08:28:55 -0500 2010:
2010/1/19 Hans Dieter Pearcey h...@pobox.com:
subtype 'Whatever', as enum([ qw(foo bar baz) ]), ...;
^
So the answer is use 'as'.
Yes, that is *part* of the answer. Look
Excerpts from Dermot's message of Tue Jan 19 11:00:41 -0500 2010:
my $indexer = MyApp::Local::Indexer-new(index_type='foobarquin);
I thought $_ was the value passed by the constructor arguments. In
this case, $_ ='foobarquin' and it would been used to cmp against the
strings in the array.
No,
Excerpts from Karen Etheridge's message of Fri Jan 15 19:57:14 -0500 2010:
... which lead me to MooseX::Role::Parameterized (a continued two big
thumbs up BTW), which lead me to a few discoveries that I wanted to mention
here for posterity:
I feel like a lot of this stuff works by accident and
Excerpts from Dmitry Karasik's message of Wed Jan 13 11:40:06 -0500 2010:
I thought that I should manipulate $meta, but I'm unsure how. Any ideas?
You wrote 'around x' in your example. Do you really mean around the accessor?
What if someone uses your trait with reader = 'get_x', writer =
Excerpts from Dmitry Karasik's message of Wed Jan 13 12:06:36 -0500 2010:
What if someone uses your trait with reader = 'get_x', writer = 'set_x'?
I don't know, it but wouldn't make sense in the context of that accessor
anyway.
It sounds like it would make perfect sense, given your example
Excerpts from Dmitry Karasik's message of Wed Jan 13 14:29:45 -0500 2010:
You see, bad is subjective here, unless you want to persuade me that
TMTOWTDI
is bad too. I cook my object accessors the way *I* like them, raw and
dangerous
:), and even though I agree that this liking is subjective
Excerpts from Dmitry Karasik's message of Wed Jan 13 15:11:37 -0500 2010:
The fact that you put that in the same category as tabs vs. spaces makes
me
think that you're just trolling at this point.
I guess this puts nicely the end of the argument. Thank you for tolerance
and empathy.
Excerpts from Dmitry Karasik's message of Wed Jan 13 17:47:06 -0500 2010:
I've written MooseX::Lists that implements what I wanted.
'isa' is potentially confusing, because you're using it differently from the
rest of Moose. You could
* rename 'isa' to something else (I have no good ideas)
*
Excerpts from Karen Etheridge's message of Tue Jan 05 14:15:40 -0500 2010:
You'll have multiple inheritance, which obviously sucks. I'm sorry for
my half of that. It will be straightforward for me to refactor the guts
of MooseX::Role::Parameterized::Meta::Role::Parameterizable (which is
Excerpts from Ovid's message of Tue Nov 03 11:01:12 -0500 2009:
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
Excerpts from Evan Carroll's message of Tue Nov 03 11:38:47 -0500 2009:
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
Excerpts from Evan Carroll's message of Tue Nov 03 11:55:04 -0500 2009:
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);
}
Excerpts from Ovid's message of Mon Oct 12 11:53:23 -0400 2009:
So instead of this:
package Thing;
use Moose;
with (
DoesRobot = { excludes = 'draw', aliases = { draw = 'draw_with_arm' }
},
'DoesDrawable'
);
You recommend this:
package Thing;
use Moose;
has
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 { ... }
Excerpts from John Napiorkowski's message of Tue Sep 08 12:58:41 -0400 2009:
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
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 understand the
Excerpts from Yuri Shtil's message of Tue Sep 08 19:26:57 -0400 2009:
What is the right way to see if an object has certain attribute?
if (Moose::Util::find_meta($obj)-find_attribute_by_name(foo)) {
do some stuff
}
I almost never find myself wanting this, though (except when writing
Excerpts from Yuri Shtil's message of Thu Sep 03 19:08:17 -0400 2009:
What is wrong in excluding some of the derived classes from a subtype
definition?
Like Chris said:
One of the main points to object orientation is Subtype Polymorphism
... meaning derived classes can be substituted for
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
Excerpts from Hans Dieter Pearcey's message of Thu Sep 03 20:52:02 -0400 2009:
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 =
Excerpts from Emmanuel Quevillon's message of Wed Sep 02 10:47:06 -0400 2009:
Attribute (cut_types) does not pass the type constraint because:
Validation failed for 'ValidCutTypes' failed with value { blunt = [
blunt ] } at lib/Bio/Restriction/Analysis/FrameCutters.pm line 315
where as it is
As far as I can tell we weren't waiting for anything else to be done, so I've
merged to master and pushed.
Can we do a dev release today?
hdp.
Excerpts from Emmanuel Quevillon's message of Tue Sep 01 08:29:06 -0400 2009:
I am quite new to Moose, at least I don't use all the power of it.
Anyway, I tried to create a subtype called 'ArrayRefOrHashRef' to be
able to have an attribute that could accept and array ref or a hash
ref. My idea
Background: http://rt.cpan.org/Public/Bug/Display.html?id=48849
This fails:
coerce ArrayRef[MyObject],
from ArrayRef[HashRef],
via { [ map { MyObject-new($_) } @$_ ] };
# later
has objects = (isa = ArrayRef[MyObject], coerce = 1);
It succeeds with a subtype of
Excerpts from Dave Rolsky's message of Sat Aug 15 20:12:48 -0700 2009:
I'd like to propose some changes in Array before we release. Specifically,
I'd like to make our names match names in List::(More)Util(s)
So with that in mind, I'd like to rename:
first = head
The term head is
Excerpts from Elliot Shank's message of Wed Aug 19 21:26:43 -0700 2009:
If you uncomment the one line in the code below, you get a Illegal inherited
options = (getopt_name) error. Is there any way around this?
has '+modified_attribute' = (
traits = [ qw
Excerpts from Yuri Shtil's message of Tue Aug 18 09:07:27 -0700 2009:
Is there a way to change access to a lazy attribute to read-only once
the value has been set in the builder?
No, that would be horrible. Just set it to readonly in the first place; that
won't stop a default or builder from
Excerpts from Yuri Shtil's message of Tue Aug 18 12:15:03 -0700 2009:
Actually I realized I made a mistake in my question.
I want to be able to make an attribute read only after changing it in
certain places of my code. The reason is that I want to control access
similar to private in C++;
Excerpts from Goro Fuji's message of Wed Aug 12 19:57:56 -0700 2009:
After considering this issue, I concluded that method_map related
stuff are not suitable to Package. Module may be a better place, so I
made a branch, topic/method_map-to-module. How about this?
Excerpts from Stevan Little's message of Thu Aug 13 05:45:04 -0700 2009:
Not sure if this will conflict that much as Jesse is talking about
arguments to the -import methods not regular constructor args.
You're wrong, but in a trivial way; he's talking about parameters to with().
with
I just merged the method_map_move branch into master; this takes all of the
methods that operate only on the current class's methods and moves them into
CMOP::Package (get_method, has_method, etc.).
CMOP::Class still has everything to do with introspection of (possibly)
inherited methods.
This
On Wed, Jul 22, 2009 at 08:54:08PM -0400, Stevan Little wrote:
My only issue with this is that methods are not really parts of
packages, methods are class things. Perhaps we could call it
code_ref_map or something better so we can get the actual functionality,
and then Role and Class can
On Thu, Jul 23, 2009 at 12:08:14AM -0400, Stevan Little wrote:
Module, it is already there a Module isa Package and a Class isa
Module.
I know Module is there, but there's nothing in the current concept of a Perl
module that implies it is only for methods (vs. functions).
hdp.
On Thu, Jul 23, 2009 at 12:07:22AM -0400, Stevan Little wrote:
Yes, well but it also has arrays, hashes, etc etc etc. I guess what I am
thinking is (as Chris says in his response to you) a package is just a
non-anonymous namespace stash, where a Module could be more then that
(I have many
On Thu, Jul 23, 2009 at 01:21:18PM +0900, Goro Fuji wrote:
I wonder why Role inherits methods from Class.
Do you mean doesn't inherit? Right now they're basically duplicated.
Even if a role is not a Class, we can override the can() method.
package Moose::Meta::Role;
our @ISA =
On Thu, Jul 23, 2009 at 12:32:12AM -0400, Stevan Little wrote:
So, if we were to go more with the Ruby model of Module then actually
this is not that far off. Ruby modules are the entire basis of their
mixins system (which we all know is the poor mans roles). So adding
method-ish type
doy++ did a bunch of cleanup in the attribute_helpers branch, and I followed
after. So far:
Moose::AttributeHelpers::Trait::X became
Moose::Meta::Attribute::Trait::Native::X. Bag is gone.
Moose::AttributeHelpers became Moose::Attribute::Native -- all this module does
is install the
On Tue, Jul 07, 2009 at 01:51:16PM -0400, Hans Dieter Pearcey wrote:
I'm going to rename everything to live under
Moose::Meta::Attribute::Trait::Native (yes, I've come around). Short names
will stay the same.
I'm going to remove Collection:: from the trait names; I think it's
unnecessary
On Fri, Jun 26, 2009 at 04:06:28PM -0500, Dave Rolsky wrote:
Here's some initial TODOs:
* POD docs for every method provided. Some providers have docs, some
don't.
I'm going to move all POD into the Trait classes. I'm leaning towards thinking
that the MethodProviders are an implementation
On Sat, Jul 04, 2009 at 12:31:35AM +0100, Mark Morgan wrote:
In my case, I'm attempting to ensure that only a single attribute is
marked as 'asdf' for a given class. The specified attribute would be
treated specially during constuction
package My::Meta::Attribute::Trait::Highlander;
use
On Wed, May 27, 2009 at 04:40:37PM -0400, Dimitri Ostapenko wrote:
So using a role to model lower-level table I need to be able to tell
which attributes come from class and which come from role in methods
for saving and retrieving data.
Maybe you want a trait for your attributes that
On Wed, May 27, 2009 at 05:16:28PM -0400, Dimitri Ostapenko wrote:
# Need to know here which attr comes from where to be able to save into
correct table
Yes, I understand the problem. That's why I suggested a role for your
attribute class so that you can say e.g.
has foo = (is = 'ro',
On Sun, May 03, 2009 at 11:00:30AM -0700, Yuri Shtil wrote:
I have a bunch of subclasses of X like this all having similar code.
For example in the class X::Procedure I would have the same code with
procedure replaced by step.
use MooseX::Role::Parameterized
hdp.
On Sun, May 03, 2009 at 10:24:54AM -0500, fREW Schmidt wrote:
[ %{$data}-values-map-(sub { $_ + 1 }) ]
don't dereference $data; your sanity check example uses a hashref, not a hash,
so it works fine.
hdp.
On Thu, Apr 23, 2009 at 03:57:32PM +0100, Mark Morgan wrote:
Cheers to both yourself and Steven Little. That looks to do exactly
what I was looking for. I didn't like my current implementation, but
couldn't find an alternate way of doing same.
A parameterized role might still be the wrong
On Thu, Apr 23, 2009 at 02:43:37PM +0100, Mark Morgan wrote:
Based on the above, the adding of the attributes should be done for
the entire class once, when the role is first used. I don't like
having to wrap constructor creation to handle this, better that there
should be an
On Tue, Apr 14, 2009 at 02:41:44PM -0400, Stevan Little wrote:
around() (without calling the next method) would also work.
That won't be detectable at composition time though.
Well, if you didn't have the method, it would fail at around() time, so it
would work in the sense that it would let
On Wed, Apr 15, 2009 at 12:24:36PM -0400, Stevan Little wrote:
No, that is correct, but the actual process is that the method from the
role is composed into the class, then the around wraps it.
So no need to turn off the warning as it would not actually happen.
Er, yeah, that was my point:
On Tue, Apr 14, 2009 at 02:22:52PM -0400, Stevan Little wrote:
So, while I am not willing to change this behavior, I am willing to add a
warning so that it is not so silent anymore. So code like this will
warn you that your overriding a class method.
This is a reasonable compromise, and
On Mon, Apr 13, 2009 at 12:38:08PM -0500, Dan Harbin wrote:
I'd like for the following validation in the Class::MOP::Attribute
constructor to be removed:
(defined $name $name)
|| confess You must provide a name for the attribute;
Is there any reason Class::MOP::Attribute should
I added a note in the Moose::Meta::Role documentation yesterday to the effect
that applying a role did not do any checks to make sure that the target had not
already consumed the role you were attempting to apply.
I always find myself writing apply role unless does role.
Would anyone object to
On Sun, Mar 29, 2009 at 09:34:32PM -0400, Sartak wrote:
On Sun, Mar 29, 2009 at 9:25 PM, Stevan Little
stevan.lit...@iinteractive.com wrote:
If we want to keep it, lets keep it, but if we don't really have a reason,
lets just get rid of it.
Get rid of it. We don't pass in the meta-attr
In December, mst committed ec2e2ee5a0f010fe09d57e0176717b6b4f5671a2, which
removes the meta-attr object as the third argument to triggers, saying
unsupport passing meta-attr object to triggers because (a) it's not tested
(b) it's not documented (c) it makes it impossible to not close over
On Sun, Mar 29, 2009 at 11:40:43AM -0400, Stevan Little wrote:
Personally, I don't think we need to pass that meta-attribute, if you
really want/need it, then you can do this:
trigger = sub {
my $self = shift;
$self-meta-find_attribute_by_name('foo')-...
...
}
The only
On Sun, Mar 29, 2009 at 09:43:45AM -0500, Dave Rolsky wrote:
That's not true. For a long time, immutablized classes have not passed
the meta-attr to the trigger (except from the constructor).
ec2e2ee5 is mst's commit (Dec 9 2008) removing the meta-attr argument.
% git blame -M -w
On Thu, Nov 13, 2008 at 05:37:27PM +, Ian Sillitoe wrote:
Farm/Cow.t
.t is probably not a great extension, since most people will associate that
with test files.
.tt or .tt2 are common.
hdp.
80 matches
Mail list logo
