On Thursday 09 February 2006 22:28, Robert Cummings wrote:
> PHP is primarily a web language. Many indexes are pulled from $_GET and
> $_POST and for obvious reasons are strings. One of the convenience
> factors of PHP is that noobs don't need to think about casting their
> strings to ints to index
On Thu, 2006-02-09 at 17:10, Ian P. Christian wrote:
> On Thursday 09 February 2006 22:08, Sean Coates wrote:
> > It's cast to an integer.
>
> Ahh.. I see. That does make sense now as to why it results in the first char
> in the array - however I still think it makes more sense not to cast, but
When indexing a string, the string is cast to an integer:
(int)'file' == 0
When in a conditional expression, the string is cast to a boolean:
(bool)'file' == true
It isn't necessarily a fatal error, consider:
$keys[ '3' ]
- Evan
On Feb 9, 2006, at 4:54 PM, Ian P. Chris
> Ahh.. I see. That does make sense now as to why it results in the first char
> in the array - however I still think it makes more sense not to cast, but
> rather to give a fatal error.
PHP autocasts everywhere. This would break years worth (and thousands)
of applications.
S
--
PHP Internals
On Thursday 09 February 2006 22:08, Sean Coates wrote:
> It's cast to an integer.
Ahh.. I see. That does make sense now as to why it results in the first char
in the array - however I still think it makes more sense not to cast, but
rather to give a fatal error.
Thanks,
--
Ian P. Christian
ht
> Now, it seems that $keys['file'] == $keys[0], which makes sense why the
> issets
> return true. However...
> if ('file') echo 'true';
> will print moo, therefore 'file' == 1, not 0. Why is this different when
> using
> it as a string offset?
> IMO, using a string as a string offset, a fatal e
Can someone explain the following to me?
echo "DEBUG:\n";
var_dump($keys);
var_dump($keys['file']);
var_dump(isset($keys['NOTEXISTING']));
var_dump(isset($keys['file']));
exit;
DEBUG:
string(19) "myConsoleController"
string(1) "m"
bool(true)
bool(true)
Now, it seems that $keys['file'] == $keys
Seth Price corrected me (thanks Seth!). I actually only loose one bit
for the sign.
echo (int)pow(2, 31);
> 1073741824
echo (int)pow(2, 32);
> -2147483648
That's certainly a relief.
I don't know if there are other reasons to have unsigned integers. I
certainly don't mind having it. However
Ezra Nugroho wrote:
I probably should say integers that I can modify with bitwise operators
comfortably without changing the signs. The problem is that people may
want to do comparison after doing bitwise operations. If the sign is
changed, the comparison will not be valid, right?
That's why I
Ezra Nugroho wrote:
Uh, positive bits?
A bitfield is a bitfield. Signedness is irrelevant.
-Rasmus
Yes.
I probably should say integers that I can modify with bitwise operators
comfortably without changing the signs. The problem is that people may
want to do comparison after doing bitwi
On Thu, 9 Feb 2006, Ezra Nugroho wrote:
> I have a task that requires bitflag operations. Having only 16 bits to
> deal with is really bad (I only care about positive int). Having 32
> positive bits in PHP 6 is certainly an improvement, but if I can get all
> 64, then live would be much better.
I
> Uh, positive bits?
> A bitfield is a bitfield. Signedness is irrelevant.
>
> -Rasmus
Yes.
I probably should say integers that I can modify with bitwise operators
comfortably without changing the signs. The problem is that people may
want to do comparison after doing bitwise operations. If
Ezra Nugroho wrote:
PHP developers,
Are the requirements for PHP 6 set in stone?
I saw in the minutes from the Paris meeting that a 64bit integer has
been proposed. I am curious if it would make sense to allow integers to
be both signed and unsigned. For me personally, I would love to have
unsi
PHP developers,
Are the requirements for PHP 6 set in stone?
I saw in the minutes from the Paris meeting that a 64bit integer has
been proposed. I am curious if it would make sense to allow integers to
be both signed and unsigned. For me personally, I would love to have
unsigned 64bit integers.
I can vouch for Helmut's ibm_db2 coding prowess -- he'll need karma
for pecl/ibm_db2.
I would hold off on karma for phpdoc though, I'm not sure he knows
what he would be getting into there :)
Dan
On 2/8/06, Helmut Tessarek <[EMAIL PROTECTED]> wrote:
> I'm one of the developers of the native IBM
15 matches
Mail list logo
