multidimensional array declaration in php

[vito]

how to achieve that? it seems php doesn't support it well for a C
programmer?

i hope to use something like:

a[$i][0];

a[$i][1];

a[$i][2];

[Jerry Stuckle]

vito wrote:

how to achieve that? it seems php doesn't support it well for a C
programmer?

i hope to use something like:

a[$i][0];

a[$i][1];

a[$i][2];

The only problem i see is it should be

$a[$i][0];
$a[$i][1];
$a[$i][2];

Works as long as $a and $a[$i] are defined as arrays.

$a = array();
$a[$i] = array();
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[vito]

$a[$i] = array();
Is the above declaration legitimate?

Furthermore,
$array[$i][1] = $array[$i][1] . $line;

PHP Notice: Undefined offset: 2700 in array.php on line 16

[Jerry Stuckle]

vito wrote:

> $a[$i] = array();

Is the above declaration legitimate?

as long as $a is defined as an array, yes.

Furthermore,
$array[$i][1] = $array[$i][1] . $line;

PHP Notice: Undefined offset: 2700 in array.php on line 16

Looks like $i contains 2700. Have you initialized this element?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[vito]

>> $a[$i] = array();

>Is the above declaration legitimate?

as long as $a is defined as an array, yes.

$array = array();

for ($k = 0; $k < 10000; $k++)
$array[$k] = array();

for ($j = 0; $j < 10000; $j++)
for ($k = 0; $k < 3; $k++)
$array[$j][$k] = 0;

How to initialize?

$array[$i][1] = $array[$i][1] . $line;
PHP Notice: Undefined offset: 2700 in array.php on line 24

[Jerry Stuckle]

vito wrote:

>>>$a[$i] = array();

Is the above declaration legitimate?

as long as $a is defined as an array, yes.

$array = array();

for ($k = 0; $k < 10000; $k++)
$array[$k] = array();

for ($j = 0; $j < 10000; $j++)
for ($k = 0; $k < 3; $k++)
$array[$j][$k] = 0;

How to initialize?

$array[$i][1] = $array[$i][1] . $line;
PHP Notice: Undefined offset: 2700 in array.php on line 24

Well, in this case you're trying to initialize 10,000 * 10,000 arrays,
each with an integer. On a 32 bit system that's something like
400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
arrays themselves. Probably a bit more than you have available - the
default is around 8M.

Why would you ever try to initialize this much memory (in either PHP or
C/C++) anyway?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[vito]

Well, in this case you're trying to initialize 10,000 * 10,000 arrays,

each with an integer. On a 32 bit system that's something like
400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
arrays themselves. Probably a bit more than you have available - the
default is around 8M.

Why would you ever try to initialize this much memory (in either PHP or
C/C++) anyway?

Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.

[Jerry Stuckle]

vito wrote:

>>Well, in this case you're trying to initialize 10,000 * 10,000 arrays,
each with an integer. On a 32 bit system that's something like
400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
arrays themselves. Probably a bit more than you have available - the
default is around 8M.

Why would you ever try to initialize this much memory (in either PHP or
C/C++) anyway?

Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.

OK, here's a good place to start with arrays:

http://us3.php.net/manual/en/language.types.array.php

However, I still fail to see why you need to define 30K elements.
That's an awful lot for a PHP routine. But you know more about what
you're doing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[ybakos]

Hi vito, you can think of php arrays as being dynamic -- you don't have
to declare it's size ahead of time like in C or Java. I'm pretty sure
they dynamically resize themselves to fit their contents.

So you would just:

for (...) {
$newArray = array(1,2,3)
$myarray[] = $newArray;
}

But 10,000 can be very big; you should think about your problem
solution.

vito wrote:

how to achieve that? it seems php doesn't support it well for a C
programmer?

i hope to use something like:

a[$i][0];

a[$i][1];

a[$i][2];

[Bent Stigsen]

Jerry Stuckle wrote:

vito wrote:

[snip]

>Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.

vito,
Your code should do the trick, that is making an array of 10000 elements,
each containing an array of 3 elements, each set to integer value zero, if
that is the intention. Can't say why you get the notice. 2700 shouldn't be
an undefined offset.

Notice that Jerry keep using the word *define*. Should probably be
emphasized since you're a C-programmer. There is no explicit declaration of
a variable like you would do in C, as it is just a generic storage-place
for a value, which content can be defined or not.
Even if not defined, a legal expression of an lvalue can be assigned a
value. PHP will happily create/extend arrays or objects if needed. Used as
a rvalue (like in your case) you will get a notice of this, but it can
safely be ignored (or suppressed with @) if the use is intended.

PHP will also quite happily coerce pretty much anything into something else.
E.g. you give all $array[$j][$k] the integer value 0, but later concatenate
$array[$i][1] with something else as if a string. Sometimes such automatic
typecasting makes sense, sometimes not.
The really good thing about it, is that it lets you write rather silly
things that actually works. Really takes the r out of boring.
Just for the point:
$array= array('is what we need').'_';
$indeed=$array.= @${', Hong Kong, we got an array to'}.'fill';
$array= $indeed("of","10000 rows. Each an",$array('with',3,@${'cats'}));

....which really just is:

$array = array_fill(0, 10000, array_fill(0, 3, null));

OK, here's a good place to start with arrays:

http://us3.php.net/manual/en/language.types.array.php

However, I still fail to see why you need to define 30K elements.
That's an awful lot for a PHP routine. But you know more about what
you're doing.

Well, yeah, sometimes one just find the urge to try something and see how it
goes. Perhaps that is vito's deal.
I once tried using php to traverse 3 Mill. records from a db. Nothing fancy
I thought, just one at the time, do a "little" fiddling and occasionally
throw a chunk someplace else. Needless to say perhaps, I ended up doing it
in C instead.

--
/Bent

[Jerry Stuckle]

Bent Stigsen wrote:

Jerry Stuckle wrote:

>>vito wrote:

[snip]

>>>Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.

vito,
Your code should do the trick, that is making an array of 10000 elements,
each containing an array of 3 elements, each set to integer value zero, if
that is the intention. Can't say why you get the notice. 2700 shouldn't be
an undefined offset.

Notice that Jerry keep using the word *define*. Should probably be
emphasized since you're a C-programmer. There is no explicit declaration of
a variable like you would do in C, as it is just a generic storage-place
for a value, which content can be defined or not.
Even if not defined, a legal expression of an lvalue can be assigned a
value. PHP will happily create/extend arrays or objects if needed. Used as
a rvalue (like in your case) you will get a notice of this, but it can
safely be ignored (or suppressed with @) if the use is intended.

True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it. And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.

However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.

PHP will also quite happily coerce pretty much anything into something else.
E.g. you give all $array[$j][$k] the integer value 0, but later concatenate
$array[$i][1] with something else as if a string. Sometimes such automatic
typecasting makes sense, sometimes not.
The really good thing about it, is that it lets you write rather silly
things that actually works. Really takes the r out of boring.
Just for the point:
$array= array('is what we need').'_';
$indeed=$array.= @${', Hong Kong, we got an array to'}.'fill';
$array= $indeed("of","10000 rows. Each an",$array('with',3,@${'cats'}));

...which really just is:

$array = array_fill(0, 10000, array_fill(0, 3, null));

>>OK, here's a good place to start with arrays:

http://us3.php.net/manual/en/language.types.array.php

However, I still fail to see why you need to define 30K elements.
That's an awful lot for a PHP routine. But you know more about what
you're doing.

Well, yeah, sometimes one just find the urge to try something and see how it
goes. Perhaps that is vito's deal.
I once tried using php to traverse 3 Mill. records from a db. Nothing fancy
I thought, just one at the time, do a "little" fiddling and occasionally
throw a chunk someplace else. Needless to say perhaps, I ended up doing it
in C instead.

That's true - I've gone through some awfully large files and databases
myself. But I've never had to create an array of 30K items in PHP, either.

Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.

My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Bent Stigsen]

Jerry Stuckle wrote:

Bent Stigsen wrote:

[snip]

True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it.

That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:

unset($a);
$b = null;

"isset" returns false for both $a and $b, even though key of 'b' is present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.

I don't understand the point in that.

And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.

Not sure I follow. I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;

In other cases it, then sure it would be an error.

However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.

Would they not know? I believe the compiler will use the terms if one screws
up, allthough perhaps one should be drunk to cause it.
[snip]

Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.

Can be generated in seconds, no biggie :)

awk 'BEGIN{print"<?php";for(i=0;i<ARGV[1];i++){printf"echo\"";
n=int(35*(1+sin(i/10)));for(j=0;j<int(n/8);j++)printf"\t";
for(j=0;j<n%8;j++)printf"\040";printf("%d\\n\";\n" ,i)}
print"?>";}' 500001 bigbadacode.php

Bit of a memory-hog and pretty useless though, but it exceeds 500K.

My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.

For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.

--
/Bent

[Tony Marston]

"Bent Stigsen" <ng**@thevoid.dkwrote in message
news:45****************@thevoid.dk...

Jerry Stuckle wrote:

>Bent Stigsen wrote:

[snip]

>True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it.

That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:

unset($a);
$b = null;

"isset" returns false for both $a and $b, even though key of 'b' is
present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.

I don't understand the point in that.

You can put a value into a variable without having to define the variable
beforehand. If you attempt to read from a variable that does not yet exist
then a ntice is generated. What's so difficult about that?

>

>And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.

Not sure I follow.

If it's on the left you are putting a value in, if it's on the right you are
trying to get a value out.

I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;

In other cases it, then sure it would be an error.

>However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.

Would they not know? I believe the compiler will use the terms if one
screws
up, allthough perhaps one should be drunk to cause it.
[snip]

>Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.

Can be generated in seconds, no biggie :)

awk 'BEGIN{print"<?php";for(i=0;i<ARGV[1];i++){printf"echo\"";
n=int(35*(1+sin(i/10)));for(j=0;j<int(n/8);j++)printf"\t";
for(j=0;j<n%8;j++)printf"\040";printf("%d\\n\";\n" ,i)}
print"?>";}' 500001 bigbadacode.php

Bit of a memory-hog and pretty useless though, but it exceeds 500K.

>My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.

For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.

This tells me that you are either using he language incorrectly, or you are
a pretty poor programmer.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Jerry Stuckle]

Bent Stigsen wrote:

Jerry Stuckle wrote:

>>Bent Stigsen wrote:

[snip]

>>True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it.

That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:

unset($a);
$b = null;

"isset" returns false for both $a and $b, even though key of 'b' is present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.

I don't understand the point in that.

unset() allows the garbage collector to completely clear all references
to $a, while $b is still defined. So the former would release some
memory, while the latter just indicates the variable has no value.

Now - I agree with you that there may not be a lot of point to the
difference. Normally I don't use unset() for individual variables, but
I will use it for large arrays.

>

>>And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.

Not sure I follow. I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;

In other cases it, then sure it would be an error.

By default an undefined variable can never be an rvalue. It will not
appear as an empty string - it will generate an error.

Using the @ just hides the error message. It doesn't stop the error
from occurring, and is, IMHO, VERY BAD practice.

Now - if the variable were defined as it should have been, there would
be no error.

>

>>However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.

Would they not know? I believe the compiler will use the terms if one screws
up, allthough perhaps one should be drunk to cause it.

Depending on the error they get, yes. Very few errors mention lvalue or
rvalue, and those are not common errors. And even if the error message
indicates "lvalue" or "rvalue", the programmers don't necessarily know
what the terms mean.

>
[snip]

>>Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.

Can be generated in seconds, no biggie :)

I'm not talking about programs generated by an inefficient code
generator. I'm talking about 500K+ LOC projects generated by hand by
dozens of experienced programmers over a period of a year or more.

Code that actually works and does something useful.

awk 'BEGIN{print"<?php";for(i=0;i<ARGV[1];i++){printf"echo\"";
n=int(35*(1+sin(i/10)));for(j=0;j<int(n/8);j++)printf"\t";
for(j=0;j<n%8;j++)printf"\040";printf("%d\\n\";\n" ,i)}
print"?>";}' 500001 bigbadacode.php

Bit of a memory-hog and pretty useless though, but it exceeds 500K.

>>My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.

For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.

I think it's a decent language for what it's designed. Not great, not
bad. But highly useful and improving.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Bent Stigsen]

Tony Marston wrote:

"Bent Stigsen" <ng**@thevoid.dkwrote in message
news:45****************@thevoid.dk...

>Jerry Stuckle wrote:

>>Bent Stigsen wrote:

[snip]

>>True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it.

That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:

unset($a);
$b = null;

"isset" returns false for both $a and $b, even though key of 'b' is
present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.

I don't understand the point in that.

You can put a value into a variable without having to define the variable
beforehand. If you attempt to read from a variable that does not yet exist
then a ntice is generated. What's so difficult about that?

It's quite clearly stated in the manual, no problem there. I just
don't understand the choice of behavior.

It is the concept of "isset", which I like to take literally.
When I set the variable to null, causing the variable to appear in
$GLOBALS, why should "isset" return false?

I understand the behavior, not the choice.

>>And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.

Not sure I follow.

If it's on the left you are putting a value in, if it's on the right you are
trying to get a value out.

I gathered that was a typo. Pretty hard to mix up left and right of
Lvalues and Rvalues.
[snip]

>>My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.

For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.

This tells me that you are either using he language incorrectly, or you are
a pretty poor programmer.

Silly, how would you know how pretty or poor I am?

I don't know if I is incorrect use that flavours my opinion. Hardly a
way to solve the lack of speed. It just isn't for number crunching.
Scope-rules usually annoys me. Behavior of isset bugs me.
This bugs me:
$a = array(1,2,3);
foreach($a as &$val) $val = $val * 2;
foreach($a as $key=>$val) echo "$key = $val\n";
Returns:
0 = 2
1 = 4
2 = 4
Behavior by design, no problem, but I hate when I have to read the
fine print in the manual, if I on top of that find it illogical, then
it is a stinking pile of cow dung.

--
/Bent

[Markus Ernst]

ybakos schrieb:

>>
i hope to use something like:

a[$i][0];

a[$i][1];

a[$i][2];

[...]

for (...) {
$newArray = array(1,2,3)
$myarray[] = $newArray;
}

As Arrays are passed by value and not by reference, you can define the
new array outside the for loop.

$myArray = array();
$newArray = array(0, 0, 0);
for ($i=0; $i<10000; $i++) {
$myArray[] = $newArray;
}

or

$myArray = array();
for ($i=0; $i<10000; $i++) {
$myArray[] = array(0, 0, 0);
}

I don't know which is faster.
Anyway this does not explain the undefined offset notice, and it does
not really answer why one should do this at all :-)

--
Markus

[Jerry Stuckle]

Bent Stigsen wrote:

Tony Marston wrote:

>>
You can put a value into a variable without having to define the
variable beforehand. If you attempt to read from a variable that does
not yet exist then a ntice is generated. What's so difficult about that?

It's quite clearly stated in the manual, no problem there. I just don't
understand the choice of behavior.

It is the concept of "isset", which I like to take literally.
When I set the variable to null, causing the variable to appear in
$GLOBALS, why should "isset" return false?

I understand the behavior, not the choice.

Because null is not a value. It is specifically the *lack of a value*.
Therefore, the variable does not contain a value - it is not set.

>
I don't know if I is incorrect use that flavours my opinion. Hardly a
way to solve the lack of speed. It just isn't for number crunching.
Scope-rules usually annoys me. Behavior of isset bugs me.
This bugs me:
$a = array(1,2,3);
foreach($a as &$val) $val = $val * 2;
foreach($a as $key=>$val) echo "$key = $val\n";
Returns:
0 = 2
1 = 4
2 = 4
Behavior by design, no problem, but I hate when I have to read the fine
print in the manual, if I on top of that find it illogical, then it is a
stinking pile of cow dung.

What's illogical about it? In order to get a value out of a variable,
you need to have put a value into that variable. Nothing illogical there.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Chung Leong]

Markus Ernst wrote:

As Arrays are passed by value and not by reference, you can define the
new array outside the for loop.

$myArray = array();
$newArray = array(0, 0, 0);
for ($i=0; $i<10000; $i++) {
$myArray[] = $newArray;
}

or

$myArray = array();
for ($i=0; $i<10000; $i++) {
$myArray[] = array(0, 0, 0);
}

I don't know which is faster.
Anyway this does not explain the undefined offset notice, and it does
not really answer why one should do this at all :-)

The first one is faster, since a single array is created vs. 10000. It
also uses a whole lot less memory.

[Bent Stigsen]

Jerry Stuckle wrote:

Bent Stigsen wrote:

[snip]

>I don't know if I is incorrect use that flavours my opinion. Hardly a
way to solve the lack of speed. It just isn't for number crunching.
Scope-rules usually annoys me. Behavior of isset bugs me.
This bugs me:
$a = array(1,2,3);
foreach($a as &$val) $val = $val * 2;
foreach($a as $key=>$val) echo "$key = $val\n";
Returns:
0 = 2
1 = 4
2 = 4
Behavior by design, no problem, but I hate when I have to read the
fine print in the manual, if I on top of that find it illogical, then
it is a stinking pile of cow dung.

What's illogical about it? In order to get a value out of a variable,
you need to have put a value into that variable. Nothing illogical there.

echo $a; // Notice generated: "Notice: Undefined variable: a in ..."
$a = null;
echo $a; // No notice is generated

This makes good sense to me, since I did define it to "something",
whatever the concept of null is.

When it comes to "being set", I don't find it particularly neat. It
lacks symmetry.
If "isset" returns true, then "unset" has an effect on the system, but
if "isset" returns false, well then "unset" might have an effect, it
depends.
Not a problem, just ugly in my opinion.

--
/Bent

[Chung Leong]

Bent Stigsen wrote:

It's quite clearly stated in the manual, no problem there. I just
don't understand the choice of behavior.

It is the concept of "isset", which I like to take literally.
When I set the variable to null, causing the variable to appear in
$GLOBALS, why should "isset" return false?

I understand the behavior, not the choice.

Part of the reason is the way the global and static keyword was
implemented. These are operators, not declarations. When you use them
on variables they create entries in the current symbol table. Thus if
isset() behaves as you described, it'll always return true in the
following:

<?

function bobo() {
static $the_clown;
if(isset($the_clown)) {
}
}

?>

which wouldn't be rather unintuitive, since you never actually set the
variable.

[Bent Stigsen]

Chung Leong wrote:

Bent Stigsen wrote:

>It's quite clearly stated in the manual, no problem there. I just
don't understand the choice of behavior.

It is the concept of "isset", which I like to take literally.
When I set the variable to null, causing the variable to appear in
$GLOBALS, why should "isset" return false?

I understand the behavior, not the choice.

Part of the reason is the way the global and static keyword was
implemented. These are operators, not declarations. When you use them
on variables they create entries in the current symbol table. Thus if
isset() behaves as you described, it'll always return true in the
following:

<?

function bobo() {
static $the_clown;
if(isset($the_clown)) {
}
}

?>

which wouldn't be rather unintuitive, since you never actually set the
variable.

Yes, I guess it would, but I would say creating them in the first
place is unintuitive too. At least for global.
e.g.:

<?php
echo $a; //generates error, $a not in $GLOBALS
foo();
echo $a; //no error, $a is now in $GLOBALS

function foo() {
global $a;
echo $a; //no error
}
?>

It is not that I in a tight spot haven't made that kind of choice of
getting a feature at the cost of a less sensible behavior, in order to
avoid the need to rewrite a lot of code. But personally I would rather
just (temporarily) accept the odd effect of the modifiers, rather than
seeing other functions being adapted to it, if that is the case.

--
/Bent

[Chung Leong]

Bent Stigsen wrote:

It is not that I in a tight spot haven't made that kind of choice of
getting a feature at the cost of a less sensible behavior, in order to
avoid the need to rewrite a lot of code. But personally I would rather
just (temporarily) accept the odd effect of the modifiers, rather than
seeing other functions being adapted to it, if that is the case.

We're not looking at just a couple similiar of odd cases though.
Similiar logic pervades the language engine. Uninitialized object
properties for example. Or when you make a reference to an array
element that doesn't yet exist. Basically anytime PHP needs a blank
placeholder it sets it to null. In order to make isset() sematically
correct, you'd have to either create a new "uninitialized" type or make
null a dual-state type. Since the difference is so slight, it's really
hard to do.

The way I see it, isset()'s raison d'etre is register_globals. That's
the only sensible scenario where a programmer cannot control whether a
variable exists or not. Since register_globals is deprecated, isset()
is sort of obsolete.