trol since line-numbered BASIC has
faded. People who get into trouble with it will likely have a good
reason to be playing with fire. I say: put it in, label it
dangerous, and let the developers decide if it's right for them.
Thanks,
-Noah Botimer
--
PHP Internals - PHP Runtime Deve
oth isset() and !empty() are
valuable and to neglect either one for syntactical sugar-coating
might be an oversight. Both are different and have applications to
the concept, so both should supported in some fashion.
Thanks,
-Noah Botimer
On Jun 9, 2005, at 2:28 AM, Ron Korving wrote:
I must
Rob,
I agree with you entirely. It's possible to write this code probably
a hundred different ways which, to me, also noting the number of
posts the topic has generated, indicates that it should be supported
in the language. A common convention for a common operation seems
like a sensib
Jason,
I realize that the initial focus is for a simple replacement for a
ternary operation. However, I think it should be possible to make a
more flexible construct to address more concerns without sacrificing
much simplicity or performance, especially in an analogous case.
For example:
Ondrej and Jason,
Just pondering the proposed coalesce() variants in the context of
Ondrej's scenario I came upon two thoughts.
I forgot to mention the nice single parameter case of a coalesce()
function like this, which would return null if not set:
$x = coalesce($REQUEST['x']);
Also, t
Zeev,
My only gripe with create_function() is the inherent "dirt" involved
in handing a code-containing string to a function. I've been living
in the app development world for some time now, so my example stash
is clean out, but my notion is that, for folks who have a real, novel
applica
k);
printf("small4 & mask: %ld\n", small4 & mask);
return 0;
}
==
big1: 4294967296
big2: 4294967297
big3: 2147483647
big4: 2147483648
mask: 2147483647
small1: 0
small2: 1
small3: 2147483647
small4: -2147483648
small1 & mask: 0
small2 & mask: 1
small3 & mask: 2147483
Hi Robert,
I hate to sound like a pedant, but shouldn't anything like that be
explicit? That is, do your own check for prerequisite class variables
that need to be set in each static method? Maybe I'm missing the boat,
but I'd say that it would be something that should be at the application
l
Andi,
I tend to agree with Bob on this one. Class vs. instance is an
important distinction and, although the syntactic sugar of being able to
reference a static member directly through an object and a scope
resolution operator could be nice, I don't think the semantics are
necessarily 100% clear.
Joe,
This may be crazy, but does it make sense to think of integers in a more
defined manner? That is, ``integer'' being equivalent to a long, which
does have a guarantee on size (32-bit)? Also, some kind of long long
type for 64-bit support would have to be included. I mean, consistency
is
Joe and Andi,
I agree that long long is probably questionable right now. Something
that seems debatable to me is: should we ever promote an integer type to
a floating type, simply on value? I guess it would make sense to
enumerate the schools of thought on this and the corresponding cast to a
11 matches
Mail list logo
