Re: Mouse and Coat

2008-09-29 Thread Alexis Sukrieh

Matt S Trout a écrit :

No, the fight was because you weren't really trying to be compatible at
that point, more "inspired by".


False. You were clearly saying I was wrong telling a 
compatible-light-weight Moose was a good idea.


I can remember that pretty well, I have to say.

I can see now that there's Mouse you've changed your weapon, the idea is 
good but Coat is bad, again, I'm in the wrong side.


Anyways, even if Coat is left behind, I'm happy to see that with Mouse, 
the idea is a good one, afterall.


Regards,

Alexis.


Re: Mouse and Coat

2008-09-29 Thread Alexis Sukrieh

Hey,

For the record, I'm just remembering, I've done a page a month ago or so 
for listing any feature supported by Coat:


http://www.sukria.net/perl/coat/features.html

Regards,

Alexis


Re: Mouse and Coat

2008-09-28 Thread Alexis Sukrieh

Hi,

Sartak a écrit :

Hi Alexis,

I've been aware of Coat since you started it. (But I hadn't seen the
value of a lite Moose until much later). I had even contributed two
patches. :)


Indeed, and I thank you for that ;)


I started Mouse (originally called Neutrino) a few months ago for fun,
to better understand how Moose fits together. It wasn't going to be
anything serious or used by anything. But then I mentioned it to a few
people and here we are.


Ok,


Mouse strives very hard to be a *compatible*, fast, light replacement
for Moose. Coat is the latter two. It's marginally compatible, but
running s/Coat/Moose/g will probably not work for a decent sized
project. 


Maybe, but I think I should precise my baseline when I'm at working on 
Coat:


Coat should be as compatible as possible to Moose when it's not about 
meta. To be short: there's no point to rewrite Class::MOP, I don't think 
a tiny-fast-perl5-core-only code will be able to do what Class::MOP does.


After talking with Stevan on IRC a couple of months ago, we agreed on 
that: if you need strong meta information, go use Moose; otherwise, it's 
a descent target for Coat to be a light-remplacement.


Yes, I know, it's not already the case, and some parts are just not even 
started (like Roles) but this is a target for me. That's why I'm taking 
as many tests I can from Moose's test-suite and add them to Coat. I want 
Coat features to be as compatible as possible to Moose.


So, again, I fear we're starting to do duplicate work here, I would be 
so glad to welcome you to the Coat maintenance, if you'd like to ;)



There are too many details that are different. For example,
if you leave out the "is" option to "has" in Coat, you get a
read-write accessor. In Moose, you get no accessor (not even
read-only). Coat probably did this to optimize for convenience. But it
is something you have to know about when upgrading from Coat to Moose.


Well, as I said above : this is a bug in Coat. Every Moose's feature 
implemented in Coat should behave like in Moose, as long as it doesn't 
involve meta-data exposition.


I'm going to fix that soon, hopefully I can find a test that put that 
issue into the light).




I've tried to model even Mouse's internals on Moose as well. I have
Mouse::Meta::Attribute, Mouse::Meta::Class->linearized_isa, etc. Mouse
does provide a very barebones MOP, but that's often all you need.
Almost all of the features provided by Mouse's MOP are given the same
name and functionality as Moose. Even if you use the MOP you can
probably safely upgrade from Mouse to Moose. Coat's MOP is quite a bit
different (not bad, just different).


Then we have a divergence of concept there. Indeed Coat's MOP is 
different from Moose's, for the reasons I explained before.




There are a number of Moose features (such as practically all the type
features) that Coat has that Moose doesn't have yet. Coat::Persistent
is also nowhere to be seen in Mouse. So I think there's plenty of room
in this space for two (or five) lightweight Mooses. :)


I don't think Coat::Persistent as something to do with this debate ;) 
It's just an ORM that is using Coat.


Anyways, as the Perl mantra said: "there's more than one way to do 
it"[1], so I understand your path, but don't forget you're more than 
welcome if you like to contribute to Coat (event tests that shows up bug 
of Moose's compatibility).


Regards,

Alexis

1: by the way I had to fight a little when I starting working on Coat, 
some people were angry because of the idea behind Coat; I'm happy to see 
that, at the end, I was right: there's is room and even need for 
light-weight Mooses.


Re: Moose -> Mouse -> Mouse::Tiny/Muscle

2008-09-28 Thread Alexis Sukrieh

Hello,


On Tue, Sep 9, 2008 at 9:30 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:

Sartak wrote:

[...]  Ideally, what I want is Mouse::Tiny,
or as I like to put it, "Muscle". [2]  A stand-alone, single file, no non-core
dependencies, 5.6 compatible implementation of 80% of Moose.  That way I can
just copy it into the Test::Builder2 distribution and have a real OO system.

I'd love to see Mouse itself go this way. There's little point in
having a lightweight Moose that has a number of dependencies
(especially XS). It looks like we could make all the dependencies
optional, and only required if you use the features.


May I ask why you didn't take a look at Coat?

http://search.cpan.org/~sukria/Coat-0.333/lib/Coat.pm

It's exactly what you're looking for, if I understand you well. I fear 
we're going to do duplicate work here :-/


Coat already supports Moose's attributes declarations, class extends 
facilities, after/before/around modifier, type-constraints facilities 
(inclunding subtyping and parametrized constraint, and is 100% Perl 5 
native.


It looks like you're restarting the work I did when I wrote Coat.

Regards,

Alexis


Re: Multiple coercions ?

2008-09-24 Thread Alexis Sukrieh

Charles Alderman a écrit :
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.


It's really funny how you can be flagged "newbie" at the first mistake 
you make.


Indeed, I totally forgot that Moose grows so quickly that my fresh 
_stable_ Ubuntu system would be far too old for a bug-proof version of 
Moose.


Indeed, this is my fault. I apology for that.

But please don't start to judge people with the first email/mistake you 
see from them.


You don't want to do that.


Alexis.


Re: Multiple coercions ?

2008-09-24 Thread Alexis Sukrieh

Charles Alderman a écrit :


This works for me:

> [...]

I've just ran your test-script, and I got the same error.

This is an Ubuntu 8.04 system, the Moose that comes with is 0.31, maybe 
this is a bug of that version?



Alexis.


Re: Multiple coercions ?

2008-09-24 Thread Alexis Sukrieh

Alexis Sukrieh a écrit :

Find attached the test script:


Hmm, sorry, looks like the attachment gets droped by the ML.
Here is the pure paste:


$ cat multiple_coercions.t

use Test::More 'no_plan';
use strict;
use warnings;

sub time_to_datetime($) {
my $time = shift;
my ($sec, $min, $hour, $day, $mon, $year) = localtime($time);
$mon++;
$year += 1900;
$sec = sprintf('%02d', $sec);
$min = sprintf('%02d', $min);
$hour = sprintf('%02d', $hour);
$mon = sprintf('%02d', $mon);
$day = sprintf('%02d', $day);
return "${year}-${mon}-${day} ${hour}:${min}:${sec}";
}

# Types & Coercions
use Moose::Util::TypeConstraints;

subtype 'Date'
=> as 'Str'
=> where { /^\d\d\d\d-\d\d-\d\d$/ };

subtype 'DateTime'
=> as 'Str'
=> where { /^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d$/ };

coerce 'DateTime'
=> from 'Int'
=> via { time_to_datetime($_) };

coerce 'DateTime'
=> from 'Date'
=> via { "$_ 00:00:00" };

{
package Foo;
use Moose;

has 'date' => (
is => 'rw',
isa => 'Date',
);

has 'date_time' => (
is => 'rw',
isa => 'DateTime',
coerce => 1,
);
}

# fixtures
my $date  = '2008-09-12';
my $date_time =  '2008-09-12 00:00:00';

my $o = Foo->new;
is( $date, $o->date($date), "date set to $date" );
ok( $o->date_time($o->date), 'coerce date_time from date' );
is( $date_time, $o->date_time, 'date_time correctly coerced' );

ok( $o->date_time( time ), 'coerce from Int' );


Re: Multiple coercions ?

2008-09-24 Thread Alexis Sukrieh

Charles Alderman a écrit :



Now - and that's where the issue gets in the scene - if I add another
coercion for the DateTime subtype, but from another source, it won't
work :


Are you sure you haven't defined the coercion to "DateTime" from "Int" 
somewhere else?


Sure.

Find attached the test script:


$ perl multiple_coercions.t
The type coercion for 'DateTime' has already been registered at 
/usr/share/perl5/Moose/Util/TypeConstraints.pm line 289
	Moose::Util::TypeConstraints::_install_type_coercions('DateTime', 
'ARRAY(0x85350fc)') called at 
/usr/share/perl5/Moose/Util/TypeConstraints.pm line 218
	Moose::Util::TypeConstraints::coerce('DateTime', 'Date', 
'CODE(0x8479f60)') called at multiple_coercions.t line 35

# Looks like your test died before it could output anything.


Alexis.


Multiple coercions ?

2008-09-24 Thread Alexis Sukrieh

Hello there,

I'm a bit puzzled by something I found when hacking on Coat and I'd like 
to have your point of view on this.


Let's say we have the folloiwng types:

  subtype 'Date'
  => as 'Str'
  => where { /^\d\d\d\d-\d\d-\d\d$/ };

  subtype 'DateTime'
  => as 'Str'
  => where { /^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d$/ };


  coerce 'DateTime'
  => from 'Date'
  => via { "$_ 00:00:00" };


And a class that has two attributes:

{
package Foo;
use Moose;

has 'date' => (
is => 'rw',
isa => 'Date',
);

has 'date_time' => (
is => 'rw',
isa => 'DateTime',
coerce => 1,
);
}

This works pretty well: as expected, I can coerce date_time from a 
Date-valid value :


Perl> my $f = Foo->new
Foo=HASH(0x85567d0)

Perl> $f->date_time('2008-02-11')
2008-02-11 00:00:00


Now - and that's where the issue gets in the scene - if I add another 
coercion for the DateTime subtype, but from another source, it won't work :


coerce 'DateTime'
=> from 'Int'
=> via { time_to_datetime($_) };

Perl> use Foo
[!] The type coercion for 'DateTime' has already been registered at 
/usr/share/perl5/Moose/Util/TypeConstraints.pm line 289


Moose::Util::TypeConstraints::_install_type_coercions('DateTime', 
'ARRAY(0x862add0)') called at 
/usr/share/perl5/Moose/Util/TypeConstraints.pm line 218
Moose::Util::TypeConstraints::coerce('DateTime', 'Date', 
'CODE(0x862a8b4)') called at Foo.pm line 37

require Foo.pm called at (eval 2) line 3



So it looks like, with Moose, when you define a coercion, a subtype is 
defined under the table, hence it's not possible to define more than one 
coercion for a given type.


Am I doing something wrong here? Is it supposed to be possible? If not, why?

For the record this works pretty well with Coat/Coat::Types and I think 
it should with Moose.


Thanks.

Alexis.


Re: Moose Role Call

2008-01-22 Thread Alexis Sukrieh

Robert Hicks wrote:

Stevan Little wrote:

Anyone on the list other than me and Yuval?


Well, looks like I'm here too :-)

Congrats for the last M00se release, it just rocks.

Cheers,

Alexis