Login | Register
My pages Projects Community openCollabNet

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

Reply to message

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

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-03-28 12:43:57 PST
Message Hi Alan,

Good questions -- and that's why this is a discussion rather than a
decision. I personally do think that if it is added at all it should be
toggle-able, yes. API docs is a good argument for keeping more
traditional methods. Bear in mind, though, that the getter/setter
methods are all doing almost the exact same thing, so I think from a
readability perspective consolidating that would help. Also, if I
understand the proposals, you could still always override the methods in
the stub methods, so for the important stuff the API docs would still
work as expected.

-- I haven't looked over these proposals yet, but I guess in my mind I
see __call() as a replacement for the _standard_ get*()/set*() methods &
not for the other methods of the class. Others may have other ideas.


Alan Pinstein wrote:
> 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.
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org