Please scratch that first parahgraph because it's incoherrent and I'm crazy:
Overloading undef would be cool. This way Joe Coder can make it act
however he'd like when it's not used in the various contexts or
operations -- string, math, smart ... Basically we would subclass (something) to
to define the behavior of all undefs declared within the
given scope. Since each undef is a magic object, it doesn't lose its
effect when undef variables are passed to methods enforcing different
undef behaviors because it carries the behavior from whence it was
defined.
On 12/16/05, Sebastian <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Overloading undef would be cool. This way Joe Coder can make it act
> however he'd like when it's not used in the various contexts or
> operations -- string, math, smart ... Basically a pragma (or
> something) would define the behavior of all undefs declared within the
> given scope. Since each undef is a magic object, it doesn't lose its
> effect when undef variables are passed to methods enforcing different
> undef behaviors because it carries the behavior from whence it was
> defined.
>
> Of course this might create problems when you want a native undef, so
> it might be cool to have some Perl.undef() which returns one.
>
> I thought of maybe a pragma, but it'd be easier on the programmer to
> consider undef as an object like anything else, which has overloadable
> methods.
>
> A method trait stating "return undef if an 'undefined value' error
> occurs" might be neat, too. Something like this might translate into
> executing the sub in a try/catch such that if the undef error occurs,
> undef is returned
>
> - sebastian
>
> On 12/16/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> > Something else I've been thinking about, as a tangent to the
> > relational data models discussion, concerns Perl's concept of
> > "undef", which I see as being fully equivalent to the relational
> > model's concept of "null".
> >
> > The root question of the matter is, what does "undef" mean to you?
> >
> > To me, it means "unknown", utterly and completely.
> >
> > Therefore, it does not make logical sense for any expression to
> > return a defined value if it expects defined arguments and is given
> > undefined ones.
> >
> > For example:
> >
> > $foo = 4 + 3; # 7
> > $bar = 5 + 0; # 5
> > $baz = 6 + undef; # error
> >
> > What Perl 5 and Pugs both currently do in the last example is
> > automagically convert the undef to a zero and put 6 in $baz.
> >
> > Likewise, with string examples:
> >
> > $f = 'hello' ~ 'world'; # 'helloworld'
> > $r = 'one' ~ ''; # 'one'
> > $z = 'beer' ~ undef; # error
> >
> > But Perl 5 (equivalent) and Pugs will cast the undef as an empty string.
> >
> > I see the behaviour of Perl 5, which Pugs currently emulates, as
> > being very, very wrong, and should be changed in Perl 6.
> >
> > An undefined value is NOT the same as zero or an empty string
> > respectively; the latter two are very specific and defined values,
> > just like 7 or 'foo'.
> >
> > Undef, by definition, is different from and non-equal to everything
> > else, both any defined value, and other undefs.
> >
> > Therefore, I propose that the default behaviour of Perl 6 be changed
> > or maintained such that:
> >
> > 0. An undefined value should never magically change into a defined
> > value, at least by default.
> >
> > 1. Any expression that expects a defined value as an argument, such
> > as typical mathematical or string operations, and gets an undefined
> > argument, will as a whole have undef as its value, or it will fail.
> > Examples are the expressions "$anything + undef" and "$anything ~
> > undef".
> >
> > 1a. If such an expression will always return a value, the value is undef.
> >
> > 1b. If the expression is allowed to fail, it can do that instead.
> >
> > 2. Any boolean-returning expression should return undef or false or
> > fail if given an undef.
> >
> > 2a. At the very least, "undef <equality-test-op> undef" should NEVER
> > return true, because an unknown quantity can not be claimed to be
> > equal to an unknown quantity. Rather, the defined() method, which is
> > analagous to 'IS NOT NULL', and such things are the proper way to
> > test if a variable is unknown.
> >
> > 2b. As a pseudo-exception, while undef/unknown values are
> > conceptually all unequal to each other, they should all sort
> > together; eg, calling sort() on an array of values where some are
> > defined and some not, should group all the undefs together. I leave
> > it up to discussion as to whether they should sort before or after
> > all the defined values, but one of those choices should be picked for
> > predictability.
> >
> > 3. In specific debugging situations, displaying an undefined value
> > could print some user-visible text, such as '<undef>' (similar to
> > Pugs' <obj:Foo>), so it is clearly distinguishible from a defined but
> > empty string. But I'm not a stickler for some other specific
> > solution.
> >
> > 4. Plain assignments or value passing will still work the same as
> > before; it is perfectly valid to pass around values whose values we
> > know we definitely don't know or possibly don't know, if we're not
> > trying to actually use them. This includes assignment into composite
> > type attributes.
> >
> > 5. In any situation where a developer wants an undefined value to
> > become a zero or empty string or something else, they should say so
> > explicitly, such as with:
> >
> > $foo = undef // 0;
> > $bar = undef // '';
> > $baz = undef // $MY_DEFAULT;
> >
> > The fact is, that in any normal program, using an undefined value as
> > if it were a defined one is a bug. Normally there will be a point
> > where such a variable should be tested for definedness and either be
> > given a default value explicitly or fail. Checking your input at the
> > gates is good programming practice.
> >
> > Going further, I propose perhaps that the standard math and string
> > etc functions simply throw exceptions if given undefined input,
> > similarly to when one tries to call a function with a mis-matching
> > argument signiture. Bring it to a programmer's immediate attention
> > that an undef is invalid for the operation, so they can fix it. A
> > simple warning that then merrily has them go on their way with a slap
> > on the wrist is too weak.
> >
> > But if you don't decide to make the undefined value warnings fatal
> > like I suggest, then my earlier (#1) suggestion of returning undef
> > should be what is done when the program is allowed to merrily
> > continue, rather than returning a defined value. This is because a
> > defined value doesn't actually make sense.
> >
> > Now, in the spirit of TMTOWTDI, such as for people that like to turn
> > strictures or warnings off, I suggest that there can be an optional
> > feature, perhaps a pragma or better a core module, where a developer
> > can say that they want undefs to automatically become zero in numeric
> > contexts or an empty string in string contexts, or false in boolean
> > contexts, etc. But they should have to explicitly activate that
> > feature, like saying "treat undef as 0 in all my code", and this
> > treating would not happen by default.
> >
> > Alternately, the meta-class that usual or standard classes are based
> > on could include a property or trait or something that lets users
> > explicitly say what happens when a container/variable of that class
> > is undefined and one tries to use it in a defined context; eg:
> >
> > By default:
> >
> > submethod value_when_undef() { return undef; }
> >
> > For a number class, could be overridden with:
> >
> > submethod value_when_undef() { return 0; }
> >
> > Or with a string:
> >
> > submethod value_when_undef() { return ''; }
> >
> > So users could get such defaulting behaviour automatically, but it
> > doesn't happen by surprise because they still explicitly overwrote
> > that method.
> >
> > But this method is better yet because users can then get that
> > functionality with arbitrary other classes that Perl 5-ish has no
> > magical conversion for.
> >
> > Installing a method like that is like SQL's "DEFAULT" clause in its
> > domain/data-type definitions.
> >
> > Note that what value_when_undef() actually returns is an object.
> >
> > But still, the default action should be that undef never becomes
> > anything magically, which aids in avoiding bugs. Such as when you're
> > using a value that you thought you tested but actually didn't.
> >
> > Automatic changes of undef into defined are non-intuitive, and can
> > confuse people who don't expect them. Less is more.
> >
> > Having users explicitly set defaults with //, or by setting a
> > defaults method, makes the program more self describing, as you can
> > see what it is doing in the code, and it isn't doing anything without
> > saying so.
> >
> > My suggestions should not make Perl slower or more difficult to use.
> > They should in fact make it easier to use. And not significantly
> > more verbose.
> >
> > Feedback?
> >
> > FYI, I feel more strongly about this issue than about the other
> > relational things I mentioned, since the undef thing is more low
> > level and very pervasive, not to mention quite simple to fix.
> >
> > -- Darren Duncan
> >
>
