On Jun 14, 2010, at 8:05 PM, Oliver Charles wrote:
On Tue, Jun 15, 2010 at 12:01 AM, Stevan Little
<[email protected]> 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.
Yes, that is true, however the test script had the call to ->start-
>month_name which made the desired results ambiguous.
Personally I do not agree that using 'undef' to mean a 'value that is
missing' is a good idea. Moose provides the predicate functionality
for just such an reason. The chief complaint is that you cannot do this:
my $foo;
my $o = Class->new( foo => $foo );
and instead have to do this:
my $foo;
my $o = Class->new( $foo ? (foo => $foo) : () );
and then a predicate on the 'foo' attribute would allow you to find
out of there was a value there. My personal feeling is that if you
pass an undefined value where a defined value is expected, it is a bug
and not a way of indicating "oh yeah, nevermind what I just passed to
you, it was nothing, just a false alarm".
The extension module MooseX::UndefTolerant changes this behavior such
that the undefined $foo would be ignored and the predicate would still
behave correctly. I am unsure as to how MooseX::UndefTolerant would
behave regarding coercions, but a few simple tests could figure that
out and perhaps the author will accept a patch.
FWIW, we have been talking about pulling MooseX::UndefTolerant back
into the core as an optional trait and plan to discuss it at the
upcoming YAPC::NA.
But if you do have a default value, I guess this could be a way to
capture that (along with default => )
Yeah, default would be smarter IMO, but adding a coercion to Undef
would allow you to pass in undef and have it still do the right thing.
If you have a Maybe[`a] type and add a undef value, that is what will
get stored and the default will never fire.
I think the big issue here is in how one views the idea of "null" or
"undef".
It is common in databases to use NULL to represent the lack of a value
where another possible value could be. In some "strongly" typed
languages like Java or C#, a variable can be checked against null to
see if it has been defined.
But this is very different from a language like OCaml, in which it is
not really possible to have an undefined value, it simply doesn't fit
into the type system. So instead things which may or may not have a
value are wrapped in the 'option' type, which has two possible values,
None, meaning no value, and Some(`a) meaning a value of the type `a
(where `a is a type parameter). It is then possible to have a
correctly typed list of items in which some of them have no value. Of
course when you go to actually do something with these values you need
to unwrap the 'option' type and deal with it accordingly.
Obviously Moose subscribes to the OCaml approach and not the SQL/Java/
C# approach.
- Stevan
