First of all, I concede that features like autovivification and
undefs defaulting to the domain-qualified 'none' are fine as what
Perl does by default, so I retract any request to change this; I am
fine for these things to remain as they are and were.
-- Darren Duncan
P.S. FYI, permit me to i
On Sat, 17 Dec 2005, Darren Duncan wrote:
1. I accept the proposal that we just make another class that implements the
SQL concept of a null value, perhaps named Null or SQL::Null, rather than
Somebody else suggested the nicely huffmanized 'nil', which IMHO sounds
definitely interesting, alth
On Sat, 2005-12-17 at 17:27 -0800, Darren Duncan wrote:
> 3. A flag that says we know that some operation failed, such as would
> be exploited in the " err "
> situations.
> This concept is like an exception which isn't thrown but returned.
"Dropping" an exception, perhaps? :)
> 1. I accept th
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> I have occasionally felt it would be nice to be able to
PS> distinguish between shifting an explicit undef value off an array
PS> and calling shift() on an empty array without having to test the
PS> length of the array. Is that lik
I have occasionally felt it would be nice to be able to distinguish
between shifting an explicit undef value off an array and calling shift()
on an empty array without having to test the length of the array. Is that
likely to fall out of any of the current thinking? I do not want shift()
on an em
Considering all the feedback and discussion I've seen so far, I
hereby retract my earlier proposals in the 'handling undef better'
messages and offer new ones instead, which hopefully address the
issues you collectively have raised.
At the root of the issues I see here is that the meaning of '
