Christopher J. Bottaro wrote:
Richard Lynch wrote:
On Sun, May 22, 2005 3:24 pm, Christopher J. Bottaro said:
And what would make it any different from a normal recursive function?
The fact that *ANY* attempt to access a mis-typed property would kick in a
__get() call, and that's too frickin' easy to happen in code that's too
easy to fly by QA in large-scale applications springs to mind...
don't forget the noob factor - a noob could spend days trying to figure out
WTF is going on in such a situation..... we might even lose him to ASP in
that time :-/
Not saying you're "wrong" or they're "right" just that it's not quite as
simple as a normal recursive function or loop iteration.
I completely disagree. I don't mean any offense to anyone here, but I find
it kind of ridiculous for a language to restrict itself that like in this
case. Its insulting to our intelligence as programmers.
er whatever, interesting to see how easily you are insulted - I mean its a
programming language with a certain kind of implementation, which may not
be perfect, but I don't think they we're thinking of you when they wrote it.
Every recursive function runs the risk of going into infinite loop if the
programmer doesn't understand the basic concept (or makes a silly
mistake).
Just saying it's an easier silly mistake to mis-type: $whatever->fooo
instead of $whatever->foo and have that escape QA somehow.
Loops run the risk of going on indefinitely as well. Maybe PHP should
disable all forms of loops/recursion to protect the programmers from
themselves.
That does seem a bit excessive...
I was making a point. I don't see why recursion is allowed in every other
function except for __get(). I think your argument is weak about
protecting people from typos. If PHP wanted to protect people from typos,
it should force you to declare your variables.
you think its a weak argument, maybe you are missing the point - ask yourself
what the average level of php programmers is? part of the php philosophy is about
making/keeping php accessible.
I think you will find that if you we're forced to declare you [class] variables
that your __get() implementation would stop working they way it does now...
Maybe __get() should allow recursion and let the developer worry about
infinite recursion.
Is that the 11th commandment?
But, today, it doesn't, so deal with it and move on.
ditto.
I was bringing the to the table a discussion of the current behavior of
__get(). I proposed that I might be broken or maybe should be changed, and
maybe you are broken, hard to tell from here.
you start insulting my abilities as a programmer and suggest that we
shouldn't consider "moving forward" and just deal with what we have?
I think Richard is a fairly intelligent person, if he had been insulting
you I'm quite sure that he would have done a much better job ;-)
What is wrong with that? Why should PHP disallow that recursive __get()
call? It is perfectly valid recursive code. It terminates for all
cases.
if it bugs you that much, write a patch for the engine and submit it at
internals@xxxxxxxxxxxxx?
What happens if you do:
class example {
function __get($x){
return $this->recursive_get($x);
}
function recursive_get($x){
/* paste your current __get function body here */
}
}
I suspect it will work just fine at the expense of one (1) extra function
call, which is not significant in recursion.
I suspect it doesn't. If __get() is anywhere in the call stack, then
you didn't bother to test?
$this->x won't invoke a 2nd __get() call.
A recursive __get() has some serious implications to performance and
design decisions that painted you into this corner.
ditto.
Well, it doesn't have any implication on the performance of my app,
considering the code path is executed like 5% (or less) of the time.
Painted myself into this corner? Why? Because I think its easier to write
$this->myvar than it is to write $this->attrs['myvar']? Its PHP's job to
given the number of chars in the email you wrote you could have written the
extra "attrs['']" (9 chars) god knows how many times, besides if you admit
you can solve all your issues by writing the 'long' form then your argument
[below] that you need to call __get() from inside __get() in order to retrieve
1 or more calculated values to calculate the originally requested attribute
sounds bogus.
and yes this are of your implementation does seem flawed - btw we all have
flawed code running... sometimes you have to hack around a problem because
time/money is what it is, sometimes you write something that is suboptimal
because you didn't, at the time, know all there is to know about that part
of php
php isn't perfect, neither are you - find a balance, get over it.
make my life easier and more convenient.
I didn't realise php had a job, I thought it was me who had the job and
php was what I used to accomplish it....
Obviously, it's entirely possible that your Design is the most elegant
beautiful disciplined bit of code since John von Nueman... But it's more
likely, without knowing anything about you, that you've come up with this
as a result of some bad Design decisions.
Review your Design. :-)
notice the fecking smiley [hint: Richard is trying to help you, trying to
get into an argument with him is making you look bad.]
Wow, how pompous of you. Bad design, huh? Since when is it bad design to
calculate attribute values on the fly? Many "cookbook" style books have
and 'cooking' is the same as 'engineering'? (I think I'll try something
new with the cement today....)
idioms for doing this. In my case, one of the calculated values depends on
other values accessible via __get(). So why shouldn't I use __get()? The
syntax is cleaner. Btw, when I say "use __get()", I mean implicitly call
__get() via $this->attribute syntax. This whole problem does not exist if
you call __get() explicitly, but then whats the point.
the point is that that works - code that does what you want is usually
a step in the right direction.
Speaking of "good design", Python's __getattr__() behaves how I expect.
use it then?
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
