On Jun 16, 2010, at 7:14 PM, Kate Yoak wrote:
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
Moo
On 17 June 2010 03:58, Darren Duncan wrote:
>
> I believe it already was; see the thread-starter post, which had this:
>
>
> http://github.com/dexterbt1/MooseX-DataMapper
>
That specific reply was to Dan, not Dexter
Yuval Kogman wrote:
Template is obviously the One True Way to template text ;-)
Basically if there's anything objectionable about it, in the sense that the
code has some sort of opinion, it isn't just a tool, then I tend to choose a
"cutesy" name out of respect for the notion that it might not b
On 17 June 2010 00:42, Chris Prather wrote:
>
> Basic rule of thumb is "Be Respectful".
>
> The module hierarchy rose to help stop the problem that I see in the
> Ruby world of "What the hell is that Frobbing thing called again?"
> Bot::ApplesToApples is obviously some kind of IRC bot for playing
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 still
>> on.
>
> Another orthog
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 still
> on.
Another orthogonal comment: Error.pm is evil; don't use it. Try::Tiny or
TryC
On Wed, 16 Jun 2010 15:41:35 -0700
Kate Yoak wrote:
> To avoid the problem, I chose the following principle for module
> layout:
>
> 1. Define attriburtes
> 2. Define method modifiers using named subroutine references
> 3. Deal with anything else that could possibly need Moose keywords
> 4. no M
>>
>
> 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
(6/16/10 6:28 PM), Kate Yoak wrote:
>>>
>>
>> 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
On Wed, Jun 16, 2010 at 03:28:20PM -0700, Kate Yoak wrote:
> >>
> >
> > 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 beas
>>
>
> 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
On Wed, Jun 16, 2010 at 03:11:34PM -0700, Kate Yoak wrote:
> > (Unrelated, but indirect method calls are evil! Stop that!)
> >
> Indirect method calls? Whatever do you mean?
>
my $one = new Foo::Child;
This should be
my $one = Foo::Child->new;
See
http://www.shadowcat.co.uk/blog/matt-s-tr
>
> '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
On Wed, Jun 16, 2010 at 03:02:23PM -0700, Kate Yoak wrote:
> 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"); #fa
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
On Wed, Jun 16, 2010 at 5:16 PM, Stevan Little
wrote:
>
> On Jun 16, 2010, at 5:03 PM, Dan Horne wrote:
>
>> On 17 June 2010 08:51, Chris Prather wrote:
>>
>>> On Jun 16, 2010, at 4:26 PM, Dexter Tad-y wrote:
>>>
Hi Stevan,
Can you suggest an alternative namespace for this? I'll tr
On Jun 16, 2010, at 5:03 PM, Dan Horne wrote:
On 17 June 2010 08:51, Chris Prather wrote:
On Jun 16, 2010, at 4:26 PM, Dexter Tad-y wrote:
Hi Stevan,
Can you suggest an alternative namespace for this? I'll try to
come up
with another name for the project.
What's wrong with just Dat
--- On Thu, 6/17/10, Chris Prather wrote:
From: Chris Prather
Subject: Re: A MooseX ORM, an attempt
To: "Dexter Tad-y"
Cc: "Stevan Little" , "moose ML"
Date: Thursday, June 17, 2010, 4:51 AM
On Jun 16, 2010, at 4:26 PM, Dexter Tad-y wrote:
> Hi Stevan,
>
> Can you suggest an alternative na
On 17 June 2010 08:51, Chris Prather wrote:
> On Jun 16, 2010, at 4:26 PM, Dexter Tad-y wrote:
>
> > Hi Stevan,
> >
> > Can you suggest an alternative namespace for this? I'll try to come up
> with another name for the project.
> >
>
> What's wrong with just DataMapper?
>
> -Chris
> >
>
This rais
On Jun 16, 2010, at 4:26 PM, Dexter Tad-y wrote:
> Hi Stevan,
>
> Can you suggest an alternative namespace for this? I'll try to come up with
> another name for the project.
>
What's wrong with just DataMapper?
-Chris
>
Hi Stevan,
Can you suggest an alternative namespace for this? I'll try to come up with
another name for the project.
I have updated the README for the comparison of DM with DBIC and Fey::ORM.
http://github.com/dexterbt1/MooseX-DataMapper
Thanks!
Regards,
--- On Thu, 6/17/10, Stevan Little w
Dexter,
Please do not use the MooseX:: namespace for this, it is reserved
specifically for extensions of Moose and we are trying to enforce that
more and more these days.
From what I see in your README it actually looks pretty nice. Can you
perhaps expand on what it provides over the exis
Greetings all,
I am releasing code for my attempt in writing a Moose-based ORM extension,
named MooseX::DataMapper for the mean time.
It started as a code exercise in metaclass programming, born out of a few days
offline vacation last week. Upon getting back online, I found the recent
sentimen
I should also mention if you want to be able to change the Type
internally, but not expose it as part of the public API, you could use
a private writer method (prefixed with _). See the "reader" and
"writer" properties of attributes.
--
Oliver Charles / aCiD2
On Tue, Jun 15, 2010 at 7:17 PM, Stephen Prytherch
wrote:
> Hello,
> I have small problem. I define a class 'Node' with 2 enums Action and State
> and when creating an instance it enforces constraints correctly. However
> once I’ve created an instance it doesn’t seem to enforce constraints.
>
> ..
On Jun 15, 2010, at 2:17 PM, Stephen Prytherch wrote:
package main;
my $btn = HtmlElement->new( Name => 'myButton', Type => 'Button');
$btn->{Type}='An Illegal Value';
You need to call the ->Type method, if you directly access the
underlying HASHref then you are bypassing Moose.
- Steva
Hello,
I have small problem. I define a class 'Node' with 2 enums Action and State
and when creating an instance it enforces constraints correctly. However
once I’ve created an instance it doesn’t seem to enforce constraints.
At the end of the following code if I dump $btn I see:
DB<5> x $btn
On Tue, Jun 15, 2010 at 12:01 AM, Stevan Little
wrote:
> Try coercing from Undef to create a default DateTime instance.
I don't think this has much meaning though - if something is undef, it
means it's not present - but defaulting to the current date has an
entirely different meaning.
But if you
28 matches
Mail list logo
