If a several pieces of data is going to be accessed a lot, in a loop, is it worth the performance gain to have the client grab the data directly from the property rather than go through an entire function call using a getter?
I think so, but I'm also starting to feel the pain of maintaining backwards-compatibility. It's difficult to keep deprecated properties functional (you'd have to replicate the data in different formats), while getter methods can be converted into facades for the new interface. I can do a global replacement on code that directly access properties that's under my control, but I risk breaking something for other developers who have modified my code.
I was thinking a possibility was to set up getters and setters for unofficial code, and then have a "secret" interface of direct access for my internals for speed reasons. An end-user would usually use the getters and setters, but could use the secret interface at their own peril.
Any thoughts on the subject?
Getters and Setters versus Performance
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
-
nickvd
- DevNet Resident
- Posts: 1027
- Joined: Thu Mar 10, 2005 5:27 pm
- Location: Southern Ontario
- Contact:
Re: Getters and Setters versus Performance
My thoughts would be... so?Ambush Commander wrote:...but I risk breaking something for other developers who have modified my code.
They modified your code, they have to be aware of the potential consequences... You don't see phpbb bending over backwards to support mods that directly modify the core code...
It boils down to one rule in my opinion. If you modify the core code of the application/library, you WILL cause all future upgrades to be quite a bit more painful.
Re: Getters and Setters versus Performance
I believe many people would define a property as syntactical sugar for getX and setX methods.. So i'm presuming you're talking about a class variable?Ambush Commander wrote:If a several pieces of data is going to be accessed a lot, in a loop, is it worth the performance gain to have the client grab the data directly from the property rather than go through an entire function call using a getter?
Ok, this more or less seems to confirm you're talking about a class variable (field) when you say 'property'Ambush Commander wrote: I think so, but I'm also starting to feel the pain of maintaining backwards-compatibility. It's difficult to keep deprecated properties functional (you'd have to replicate the data in different formats), while getter methods can be converted into facades for the new interface. I can do a global replacement on code that directly access properties that's under my control, but I risk breaking something for other developers who have modified my code.
- First step to do is mark the property as deprecated (that way you can kick it out in a release or two
- Second step to do is remove the public variable and implement the facade using the magic __get/__set functions (this way it will appear as if the variable still exists and you keep backwards compatibility).
I don't think it's a good idea to give your own code more privileges because it results in the same problems as you mentionned above... (and source code doesn't have secrets anyway...)Ambush Commander wrote: I was thinking a possibility was to set up getters and setters for unofficial code, and then have a "secret" interface of direct access for my internals for speed reasons. An end-user would usually use the getters and setters, but could use the secret interface at their own peril.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I'm not quire sure if i already shared this thought.. But for a long time i had been wondering what the use of properties was.. Since they're only (seemed to be) syntactical sugar for setX and getX methods... The usefulness of properties is the fact you can silently replace class variables and upgrade them to functions.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Quick note, this is PHP 4, so using __get/__set to simulate is not workable. And yes, we're talking about class variables. Sorry about not being clear about that.
I have no mercy for users who patch my code.
Okay. It's seems like asking users to cache the data locally would be a good idea. In fact, it happens to a certain extent in my own code, so I don't end up with things like:
Which brings in another monkey-wrench: these are not "simple" class variables. That's a fairly normal call, which will occur hundreds of times, with varying $token->name and $attr_key values. Even if I did cache the accessor's return value, I'd end up calling it several times on different iterations of the loop. If I try to fix up I'd end up building a mirror image of the data-structure and interface directly off of that (which might not be a bad idea. The object is not outrageously large).
Sorry. I mean developers who used public, but very internal, APIs....but I risk breaking something for other developers who have modified my code.
But thing is if it's my code, I can make some global changes and restructuring to make things work better. Not happy with a method name? Rename and do a file-wide string replace! But a property name, hmmm...I don't think it's a good idea to give your own code more privileges because it results in the same problems as you mentionned above... (and source code doesn't have secrets anyway...)
Okay. It's seems like asking users to cache the data locally would be a good idea. In fact, it happens to a certain extent in my own code, so I don't end up with things like:
Code: Select all
$definition->info[$token->name]->attr[$attr_key]->validate(...);