On Sat, Dec 17, 2005 at 12:12:15PM -0800, Ashley Winters wrote:
: Explicitly nil values wouldn't warn or fail on activities which undef
: does. nil is basically a value which is simultaneously '' and 0 and
: 0.0 and false *and* defined, and allows itself to be coerced with the
: same rules as perl5
> "DD" == Darren Duncan <[EMAIL PROTECTED]> writes:
DD> At 9:30 AM + 12/17/05, Luke Palmer wrote:
>>
>> You're actually saying that undef either compares less than or greater
>> than all other objects, which contradicts your earlier point. I'd say
>> it just fails.
DD> At th
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 '
On Friday 16 December 2005 22:25, Darren Duncan wrote:
> At 10:07 PM -0800 12/16/05, chromatic wrote:
> >This is fairly well at odds with the principle that users shouldn't have
> > to bear the burden of static typing if they don't want it.
> This matter is unrelated to static typing. The state
On 12/17/05, Sebastian <[EMAIL PROTECTED]> wrote:
>
> Obviously there are mixed opinions of how undef should be treated and
> some won't be happy with what becomes final, so implementing some
> intelligent defaults and simple pragmas, but not excluding the ability
> to *really* control your undefs,
I still think it'd be neat to have a special Undef class of some sort
which can be subclassed and further defined to really DWIM rather than
be stuck with whatever pragmas Perl has graciously built in. Something
like this would require more thinking and speculation -- and it may
hurt performance to
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Actually, you can think of undef pretty much as defining
LP> autovivification. "If you use it as a number, it becomes a number; if
LP> you use it as a string, it becomes a string; if you use it as a hash,
LP> it becomes a hash; ...
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
[snip]
> 2. Until a value is put in a container, the container has the
> POTENTIAL to store any value from its domain, so with respect to that
> container, there are as many undefs as there are values in its
> domain; with some container types,
On 12/16/05, Darren Duncan wrote:
The root question of the matter is, what does "undef" mean to you?
To me it means nothing. (I'm so callous.)
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
Gordon Henriksen schreef:
> I find it useful to distinguish between unassigned and undefined
> (null).
I am not sure that you need this distinction, but it should be no
problem to have it, just like 'tainted' and 'NaN' and 'zero/empty' and
'error'.
> I find null propagation frustrating; it's mo
Darren Duncan schreef:
> A variable whose value is undefined is still a typed container; eg:
>
> my Int $z; # undef since not assigned to
> my Str $y; # undef since not assigned to
If 'undef' becomes 'fail' at the same time that those base types don't
have default start-values such as 0 and '
I find it useful to distinguish between unassigned and undefined (null).
"None" is very often a valid value, especially for primitive types, and
especially where databases are involved. i.e., the range of a variable might
be {undef, -2^31..2^31-1}. In my experience:
99 + undef -> 99 #
At 9:30 AM + 12/17/05, Luke Palmer wrote:
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Undef, by definition, is different from and non-equal to everything
else, both any defined value, and other undefs.
You said "by definition", but where is this definition?
Maybe "definitio
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> 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'.
I definitely agree with you in principle. This is something that has
been bugging me,
At 2:27 AM -0500 12/17/05, Gordon Henriksen wrote:
I find it useful to distinguish between unassigned and undefined (null).
I think that the whole point of having "undef" in the first place was
to indicate when a container wasn't assigned to yet, and hence has no
useable value. Also, that ex
15 matches
Mail list logo
