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 =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Date 2006-03-28 16:03:39 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.

I don't think it's _that_ much of a deal. The function name alone
tells you which field it gets or sets, and the already generated
documentation is absolutely useless. You usually only document
extensively (for instance, optional parameters, behavioral stuff etc)
if you implement your own code in the stubs, and that's where it's
still possible.

> 2) How do __call/__get/__set work with subclasses? How does
> overriding work?

It works as usual, no change there.

> 3) If this behavior is added, shouldn't it be TOGGLE-ABLE?

Yeah why not we can have a thousand different builders if people
desire ;)

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

For a table with many fields, these add up quickly, especially in
case of getters and setters for related objects. I expect the
difference in parse time to be quite significant.