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...
>
> 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.
>> 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.
> Maybe __get() should allow recursion and let the developer worry about
> infinite recursion.
>
> But, today, it doesn't, so deal with it and move on.
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
you start insulting my abilities as a programmer and suggest that we
shouldn't consider "moving forward" and just deal with what we have?
>> What is wrong with that? Why should PHP disallow that recursive __get()
>> call? It is perfectly valid recursive code. It terminates for all
>> cases.
>
> 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
$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.
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
make my life easier and more convenient.
> 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. :-)
>
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
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.
Speaking of "good design", Python's __getattr__() behaves how I expect.
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
