On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
> > I think that this is better done as a special overloaded object used
> > by database modules which wish to implement SQL-style tri-state logic.
> 
> It could be done as an overloaded object.  You'd have to be able to overload all
> the operators, both numeric and string.

This can be done.  "perldoc overload".


> > The one thing which this requires that Perl5 does not have is the
> > ability to overload the defined() operation on an object.
> 
> And what about overloading the ternary ?: operator?  Of course, that one can be
> avoided.

Overload conversion to bool, and you have this trivially.


> Not usable, I get lots of "Use of uninitialized value in print" warnings, and do
> not have use strict.

I suggest that you read up on the difference between "use strrict" and
"use warnings"/-w.

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.


> > Incidentally, I'm surprised that DBI hasn't added an option to use
> > an overloaded null object, if this feature is in demand.
> 
> Performance.

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.

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.

                       - Damien

Reply via email to