> -----Original Message----- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Sent: Monday, 19 April, 2004 06:00 AM > To: Language List > Subject: A12 undef method calls > > > A12 mentions that C<$foo.bar> should return undef if C<$foo> is undef. > While I like the idea a lot, I don't think it should happen without > distinction. In fact, that's what I would most expect C<.?> to do, not > "call a method if there is one," though that seems useful, too. > > I'm just shooting in the dark here, but perhaps C<?.> should play that > role. That way you have: > > $foo.?bar # return undef if "bar" is undef... in a > manner of speaking > $foo?.bar # return undef if $foo is undef > $foo?.?bar # return undef if either is (?) >
I think that undef->undef is desirable default behavior, not something that should have to be spelled out over and over again. There are really four cases. Assuming errors in all: 1- Untyped/Undefined: "I don't know *WHAT* you want." 2- Typed/Undefined: "I know what you want, but you can't get it (yet)." 3- Untyped/Defined: "I know what you want, but this object doesn't support it." 4- Typed/Defined: "I know what you want, and this is plain wrong." I think that 3 and 4 should throw exceptions, as being clearly wrong (unless AUTHMETH[DEF] is present). 1 and 2 on the other hand are more in the region of "easygoing DWIMery", so should just return a helpful undef, unless C<use jackbooted_object_nazi;> is in effect. > Either that or C<.?> could double as both roles, considering C<undef> > an object with no methods. Ugh. Let's make '.' as useful as possible, please. > And I can't figure out for the life of me why you'd ever want to use > C<.+>... This is probably the "should be" default for '.': "Call a method. If there's more than one, figure out what to do about that case and do it. But make sure that SOMETHING gets done, or let me know why not." =Austin
