On Fri, Jul 23, 2010 at 7:51 AM, Macdonald, John <
john-421.macdon...@morganstanley.com> wrote:
> Two items:
>
> 1. I was just surprised to discover that Moose::Role does not allow
> augmenting attributes.
>
> I was hoping to specify in the Role that an attribute was required, and
> most of the ch
This is a tiny bit off-topic, but TryCatch is so closely tied to Moose, this is
probably as good a place to ask as any.
I am finally switching away from Error.pm and I am looking to see how to
implement the things I am used to from Error.pm with TryCatch. It looks to me,
there is no magic that
On Jul 15, 2010, at 10:30 AM, Jesse Luehrs wrote:
> On Thu, Jul 15, 2010 at 10:11:04AM -0700, Karen Etheridge wrote:
>> On Wed, Jul 14, 2010 at 09:28:35PM -0500, Jesse Luehrs wrote:
>>> Nope... you can't magically turn a class (even a non-Moose class) into a
>>> role... roles just don't work like
Hi everyone,
Here is a stumper.
I have some non-moose code, which is intended to be subclassed - it's just a
framework.
I'd like to create a wrapper that Moosefies it. And while I am at it, I'd like
to make the framework a Role (since that's what frameworks generally are).
But any which way I
>
> I would be interested to see an example of how you would use augment and
> inner with roles. I could never picture a way to do it in which it didn't
> seem overly confusing, but I am always willing to admit to my own lack of
> imagination :)
>
> - Stevan
>
Cool! I like imaginative. I'l
>> I finally found a good place to play with inner() and augment. How come
>> inner() is called as a local subroutine instead of an object method? It
>> stands out as a sore thumb and is making me itchy!
>>
> Because inner, like super, has, extends, with, requires, augment, before,
> around,
On Jun 16, 2010, at 3:57 PM, Karen Etheridge wrote:
> On Wed, Jun 16, 2010 at 03:28:20PM -0700, Kate Yoak wrote:
>> I normally do so as early as possible so I could start using things like
>> Error.pm - and prefer not writing and "real code" with Moose namespace s
>>
>
> You don't; all of the keywords that Moose provides are generated by
> Moose::Exporter, so that they are passed the appropriate metaclass
> instance. Just move the 'no Moose' later. I'm not sure what you mean by
> "with the Moose namespace still on".
>
> -doy
Sorry, that was very awkward
>>
>
> Because inner, like super, has, extends, with, requires, augment, before,
> around, after and override, is a "keyword" and not a method.
>
>
Well, that explains a lot. It also makes my life difficult as such a beast
usually comes up long after I've said no Moose;
I normally do so as
>
> 'extends' happens at runtime, so when your test stuff is running, the
> 'extends' call hasn't happened yet. 'use' and 'package' are compile
> time, so those parts *are* set up before the test stuff starts running.
> Either move the packages up before the tests, or wrap the packages in a
> BEGI
When I define my packages right inside a script (like for testing), Moose
inheritance breaks down:
#!/usr/bin/perl
use strict;
use Test::More tests => 2;
my $one = new Foo::Child;
ok($one->can('foo'), "extends"); #fails
my $two = new Foo::App;
ok($two->can('foo'), "isa"); #succeeds
package Fo
Hey guys,
I finally found a good place to play with inner() and augment. How come
inner() is called as a local subroutine instead of an object method? It stands
out as a sore thumb and is making me itchy!
"Curiosity killed the cat" :-)
>
> If perhaps you are looking to automate CRUD using Moose metadata, several
> attempts have been made at this and IMO they all ended up with too much
> compromise and coupling. You might want to take a look at the Smalltalk
> Magritte project, they add an additional layer on top of the pure o
>
> Encapsulation demands that you should be able to replace behavior with
> state (your earlier caching example) and state with behavior without
> the outside world noticing. So at that level yes; attributes and their
> associated behaviors (accessors, readers, writers, clearers,
> predicates, et
>
>
> There are several different things going on here I think.
>
> 1) Attributes are different from Methods however
> Accessors/Readers/Writers are not. It is kind of a philosophical point
> but Attributes define the data structure that makes up the core of the
> object while methods define the
Delegation is a yet another amazing feature of Moose.
While basic delegation,
handles => { qw/uri host/ }
is nice in that it saves some typing and provides nice self-documentation
facility, but not essential. The part that looks so enticing to me is
Role-based delegation:
> On 20/05/2010, at 1:45 PM, Kate Yoak wrote:
>
>> This problem actually screams for a MooseX::ImportGlobs kind of a module.
>> It feels like one ought to be able to dig around, find all the unnamed globs
>> and import them into meta with a single line of code.
>
>
>
> after has_a => sub {
>my ($class, $method_name) = (shift, shift);
>
>my $method = Moose::Meta::Method->wrap(
>associated_metaclass => $class->meta,
>package_name => $class,
>name => $method_name,
>body => $class->meta->get_all_package_symbols('CODE')
On May 18, 2010, at 10:31 PM, Daniel Pittman wrote:
> Kate Yoak writes:
>
>> I am using an ORM, which creates methods for my class using globs, in place.
>>
>> e.g. __PACKAGE__->has_a('foo'...);
>>
>> now I have a foo() method define
>>
>> I am using an ORM, which creates methods for my class using globs, in place.
>>
>> e.g. __PACKAGE__->has_a('foo'...);
>>
>
> Class::MOP (and so Moose) recognizes methods as code symbols in a
> package that also have a valid subname (as with Sub::Name). This is
> because methods declared
Hi all,
I am using an ORM, which creates methods for my class using globs, in place.
e.g. __PACKAGE__->has_a('foo'...);
now I have a foo() method defined in my namespace.
I thought that I could use method modifiers to supplement the created methods:
around foo => sub{
.
};
This failed t
On May 14, 2010, at 9:21 PM, Jesse Luehrs wrote:
On Fri, May 14, 2010 at 09:02:54PM -0700, Kate Yoak wrote:
sub old_method {
...
}
And parent method modifiers will be skipped?
Yes, method modifiers aren't magical, they just install a normal
method
in the parent class.
Sil
sub old_method {
...
}
And parent method modifiers will be skipped?
Hi everyone,
I would like to know if there is an elegant way to override a method
with prejudice: "No, I don't want anything related to this method
inherited from the parent - I'd like to rewrite it from scratch."
What I can think of is this:
around old_method => sub{
...
$self->new_
Patches welcome, I'm sure. Join on in irc://irc.perl.org/#moose if
you're interested in working on this.
Moose is the most exciting library I've encountered since my discovery
of HTML::Mason in 2000. (Though I use TT now, it was Mason that
changed my life) I appreciate the push. Just wha
Hey guys,
I ran into some really strange behavior with method modifiers.
package Parent;
around qr/^[A-Z][a-z]/ => sub {..};
package Child;
extends Parent;
sub Foo{...};
Everything works as advertised for Parent's methods. The Child's
methods do not get the method modifier.
Changing reg
; 'Str',
default => 'human',
);
The error message certainly isn't clear, and it suggests that the
parameter
object does not exist at all in the parameterized role when you do
not pass
a parameter (which does not parallel normal Moose behaviour -- an
attribute
metao
parameter foo => (is => 'rw', builder => '_foo');
with _foo() defined above this statement, below it, inside the role
block (pretty sure it fails before getting inside the role). No
good. It says: Error: Class::MOP::Class::__ANON__::SERIAL::1 does
not support builder method ...
You shou
inside the role). No
good. It says: Error: Class::MOP::Class::__ANON__::SERIAL::1 does
not support builder method ...
What should I do?
On Apr 22, 2010, at 2:54 PM, Kate Yoak wrote:
Just a couple of notes that would be of use if they were in the
documentation:
1. The bad news: Becaus
Just a couple of notes that would be of use if they were in the
documentation:
1. The bad news: Because of the weirdness of role{} block, the child,
nor the role cannot be declared within the same file with the script.
(Like you might do while trying to test sample functionality!)
2. The g
Personally I would just have the builder in _orm_table figure this
all out? or add an instance level 'orm_table' attribute so that I
could vary it on a per-instance basis if the need ever arose.
Thanks, Stevan. My intent was to use class data for class methods
(where you don't intend
Hi all!
I want to know more about why class data is the Wrong Thing to do.
I think of class data as complex constants. For example, say, I have
a Model layer, which aggregates ORM table objects. I might have
something like this:
use constant orm_class_name =>'Table::Account';
has table (
On Apr 14, 2010, at 3:32 PM, Alex Francis wrote:
On Wed, Apr 14, 2010 at 11:27 PM, Jesse Luehrs wrote:
The actual bug here is that Class::MOP::Class->initialize shouldn't
initialize a CMOP metaclass for a class with a Moose parent (feel
free
to read up on metaclass compatibility if you're
33 matches
Mail list logo
