Posted by Steve on 04/20/07 16:36

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:yuadncQAZvYUeLXbnZ2dnUVZ_uejnZ2d@comcast.com...
| Jim wrote:
| > Hi guys,
| >
| > I have an object which represents an "item" in a CMS "component" where
| > an "item" in the most basic form just a field, and a "component" is
| > effectively a table.
| >
| > "item" objects can be created and then added to "component" objects to
| > build up the component definition.
| >
| > My dilemma comes in deciding how to read/write data to the "item"
| > object.
| >
| > I figure I can either:
| >
| > 1. Use getters and setters (hate the idea of them though)
|
| But it's the right way to go. Among other things, it makes the code
| much easier to maintain in the future.

actually, no, it doesn't. he wants to use a switch in __set/__get and call
the appropriate PRIVATE getter/setter. PLUS, in doing so, he'd have
simplified the object's interface. there is NO difference affecting the
maintainability or scaling of the object in the future.

only problem is, __set/__get only works when a *non-existent*
method/property is getted/setted.

| > 2. Use __get and __set which I prefer the idea of from a user
| > interface point of view though I understand they take no notice of
| > member visibility.
|
| You can do it - but now you have to validate the parameter - is it an
| actual value?

the parameter is always $value. all he'd have to do in his scenario is take
the __set value as a variant/non-typed variable. his private setter could
strongly type the param which would throw errors automatically in php if the
param type didn't match.

| And it will be harder to maintain in the future - more
| code to worry about when you add/delete values. Validation also becomes
| much more complicated.

i'm not sure you follow what he's saying, otherwise you'd see that your
'preferred' getting/setting is identical (though less effective) to how he's
wanting to implement __set/__get - which is only a middle-man between the
scopes of public and private. validation still happens in the same
place...getters/setters (your preference noted)...what changes is that HIS
getters/setters would have PRIVATE scope and would run automatically and
with LESS code for the developer and the end consumer. ex.,

his implementation:

$foo->bar = 'hello world';
echo $foo->bar;

yours:

$foo->setBar('hello world');
echo $foo->getBar();

to me the consumer, i *prefer* the former. now i think you can imagine what
the code for the class would be in both scenarios. i can spell that out for
you too if needed. BOTH would have setBar() and getBar() however...which is
why i can't see how you derive your 'preference' based on your point of
contention for said opinion(s).

| > 3. Pass all the required parameters to one function and do all the
| > validation there - inflexible, unintuitive and more work in the long
| > run in my opinion.

again, the same goes here. and, i'll not flog a dead horse any more than i
have to.

| About the same as using __set, isn't it?

obviously not. consumer get ONE interface to deal with in his scenario.

| From the point of clarity, ability to later modify the code, etc., I
| much prefer getters and setters. Sure it means you may have a lot of
| functions - but there won't be the independence on other code you have
| with other ways. It will probably be faster, also.

again, he's not doing away with them. he makes them private and the built-in
__set/__get takes over publically as the middle-man for the public
interface. and, as __set/__get ARE built-in, nothing you could script will
execute any faster. as for 'independence' (i think you mean loose coupling),
__set/__get of the class passes params to the appropriate private
getters/setters. since they are part of the same object, there is NOTHING to
decouple.

i hate to take the arrows from your quiver, but i just don't think you
understand the post.

finally, i must say again. __get/__set only execute from php when a
non-existent interface is accessed. so, no worries jerry, we're still suck
with public getters/setters...for now.

[Back to original message]