Re: Re: Re: Re: __get() not reentrant?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 23, 2005 8:43 am, Christopher J. Bottaro said:

You took my suggestions as flames, and responded in kind.

They were not intended as such.

I'm happy to assume that you're the best programmer on the planet, okay?

Let's cut the flames out.

> case.  Its insulting to our intelligence as programmers.

PHP was initially designed for very much non-programmers.

It's kind of gotten away from that with all the OO stuff, especially in
PHP 5, but there is still a considerable faction that doesn't *WANT* the
complexity of a full-blown kitchen-sink language.

It's not because we think you're stupid; And it's certainly not that we
think we're stupid.

It's that we believe that simple tasks are best served by simple tools.

> 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.

Or maybe it should warn you when you use an undeclared variable. Oh wait,
it *DOES* that!

Rather like Lisp, actually.

But that feature is turned off by default installation.

> 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?

I don't know why you took insult.  None was intended.

You may want to take this discussion to PHP-Dev, however, where people who
actually made the decision you don't like, and who will be the ones to
decide what to do about your suggestion discuss these kinds of decisions.

You obviously don't accept my musings on possible reasons. [shrug]

>>> What is wrong with that?  Why should PHP disallow that recursive
>>> __get()
>>> call?  It is perfectly valid recursive code.  It terminates for all
>>> cases.

You clearly don't like the answer I gave.  Maybe there's a better answer.

Berating me sure won't find it.  Try PHP-Dev.

>> 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.

You misunderstood my suggestion.

I was suggesting that you compartmentalize the __get() from the recursion,
such that there was NO $this->xyz in the function body of recursive_get().

>> 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.

The code you posted was doing quite a bit more than getting rid of an
array reference...

If that's all you want, you can do it without recursion.

>> 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.

You're not going to like my answer.  Oh well.

It seems to me that you've decided to make your property references be
just as powerful, complex, and flexible as methods.  At which point, I
have to wonder why they should be properties at all.

Why not just make it be a method?
$example->get($x);

There's not a lot of point to HAVING properties distinct from methods if
the properties are going to be so complex that they require all the power
of methods.

That's just *MY* opinion, based on a lot of different OO languages.

I expect you disagree with it, and that's fine.

But the point is there:

If you are going to put that much complexity into your property, it's not
a property any more; it's a method.

> Speaking of "good design", Python's __getattr__() behaves how I expect.

Okay. [shrug]

Perhaps you'd be happier coding your application in Python?

Nobody is forcing you to use this ill-designed PHP language. :-)

You're certainly not going to see something like this changed in hours as
a result of a thread on PHP-General.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux