|
|
Posted by Jerry Stuckle on 07/17/06 11:07
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.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|