Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] roadmap > Reply to message

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Alan Pinstein <apinstein@mac.com>
Full name Alan Pinstein <apinstein@mac.com>
Date 2006-03-28 12:29:31 PST
Message I have a few things that need to be considered before using __call/
__get/__set

1) For those of us that want API documentation for our codebase, I
don't think we can get it unless the functions are actually there.
2) How do __call/__get/__set work with subclasses? How does
overriding work?
3) If this behavior is added, shouldn't it be TOGGLE-ABLE?
4) Why do you want to do this? Before we go do this level of
changing, where are the performance results that show these changes
would make more than a negligible improvement? For instance, most of
the getters are one-liners; and most of the setters are 3-liners.

I am not sure that the overhead required by __call etc would be LESS
than the direct function call itself... don't forget that call has to
check to see if the function exists anyway, then you have to have a
bunch of code in the __call routine to "do the right thing".

So let's see some evidence that a suggested change will actually
improve performance before making a change that causes the code to be
less readable, less documented, and of unknown performance benefit!

5) Maybe there is some level of abstraction that could be used to
reduce the code?

For instance, the dts-style functions have a lot of code that could
probably be factored out into the base class to reduce these
generated functions from 20 lines of code to a single line. Same is
true of the related object fetching, setters, etc.

Alan


On Mar 28, 2006, at 10:28 AM, Hans Lellelid wrote:

>> * Utilizing dynamic __call/__get/__set in BaseObject/BasePeer classes
>> and kill much generated code from the Object/Peer classes for
>> get*/set*/add*
>>
>> If noone dislikes this I'll add two dev discussion pages to the wiki.
>>
>
> Adding the pages sounds good to me. The only concern I have (which I
> can mention in comments on wiki too) is that certain methods (temporal
> methods) take additional parameters -- which might present a problem
> __call/__get/__set, unless we just standardize on an API that does not
> support these. Just something to discuss.