Damien Neil wrote:
> I suggest that you read up on the difference between "use strrict" and
> "use warnings"/-w.
Thanks, yes, I figured out the "no warnings" issue afterwards.
> Furthermore, you may wish to take the five seconds necessary to
> understand WHY it prints that message when you print a null value
> in that code. I defined null as stringifying to undef, with the
> specific intention of producing that warning message. If you
> would prefer that it stringify to "", or to "null", this would be
> a trivial change.
Yes, I'll have to play with this more. I guess while it does only take a few seconds
to figure out the null, I have more to learn about perl before I understand the
complete object you've provided here and its semantics.
> For an optional, off-by-default feature? If a SQL-style null is
> so useful, I'm certain there are people who would be happy to
> accept the performance hit.
Well, I'd rather have it be the on-by-default feature, if performance allows,
somehow. Your module looks so short, and nice, if it really can be twiddled into a
"real" SQL null, then we could have them today in Perl5? And if they are slow,
general object improvements in Perl6 might fix that?
This idea of implementing NULL seems to come along without the baggage of
encapsulating scalar values... i.e. implementing an object consisting of
package numeric_with_null_support;
sub new { bless { null_flag => false, value => }}
is intriguing if it can be made to work. RFC 234 makes me wonder if there is a
problem with binary operators in the case where multiple NULL value packages like
yours were implemented with slightly different semantics (to mirror the mulitple NULL
values possible in SQL), when a binary operators would be applied to two different
NULL values. Of course, it is probable that all the different NULL values would be
from the same package, just with a different value, so maybe this isn't a problem.
I'm not that deep into overloading to understand the complete issue there.
> When you consider that this would be used in conjunction with database
> code which often must perform transactions via the network, I strongly
> suspect that in many cases the performance overhead of overloading
> would be nearly invisible.
Well, if you do a bunch of post-processing in Perl, that could quickly consume more
time than the original fetch of data via the network. Especially if there were lots
of NULLs, and NULL is a performance hog.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
