The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Get and Set methods are meant for external classes, not inside the class. You could argue that they're not really necessary at all, considering PHP doesn't even have private attributes...

Not really. There's some instances you may need to do something special on get or set, or if you're using php5, you may even use type hinting to enforce a certain type.

If I am setting a private method form somewhere inside a class (besides in the acutal get/set method) I normally always call the getter/setter method so that any logic I may apply inside those methods will be availble and keeps me from changing data in multiple places when changes occur.

As for arguing that get/set are not needed at all, that's not an arguement, that's a newbish claim as directly accessing all the class properties no matter what smacks of blackbox violations.

I would have like to have seen the poll be a little bit more specific as in "Do you use generic or specific accessors in your classes?", since some people (like myself), dont always use "setWhatever" when the number of attributes in a class is variable, and prefer the generic accesor flavor ("getVar('name') / setVar('name', $value)").

Anyway, I answered it as "no", meaning "I don't use specific accessors all the time, but I do use generic accessors almost always". I guess I should have chosen "undecided"

I don't understand the use of getVar('name') and it's counterpart setVar('name') within the class itself.

The only reason I can see for wanting to use get/set internally is to provide a mechanism for manipulating the target of your get/set in some non-generic way. If you use getVar or setVar, you may as well just access the property directly.

I use getter class methods where the Model interacts with the View for example. You do this because the Model parameters may change at a drop of the hat, which usually happens a lot.

You change the property names within the Model class only, you do not need to alter the View which uses the Model in that case, as the getters remain as is. As for setter class methods, I don't bother, I set the class properties publically, which doesn't really matter in my view, as it happens in the lower layers anyway.

As for not needing the use of setter and getter class methods is just pure fantasy. You do need them at some point, and you will find that you will use them. Frequently actually.

Btw, PHP5 is not rubbish. It is one of the most modern, web scripting languages on the planet. If your not particularly happy developing with PHP then fine - go and find something else to develop with.

But don't come here and start that rubbish. We've seen enough of it thank you.

The use of these methods is obvious in java, where you should general keep your variables private. I just don't see the point in PHP.

Why ? (dumb argument IMHO)

Originally Posted by Viflux

The only reason I can see for wanting to use get/set internally is to provide a mechanism for manipulating the target of your get/set in some non-generic way. If you use getVar or setVar, you may as well just access the property directly.

I came from a VB background where all object propertys are set via set and retrieved via get methods, I was astounded that php allowed such open access to class variables. In Php 5 you can have mock read only variables or mock set only variables by using set or get functions. If the variable is read only use the set function to return an error message when a user tries to set the property from code, and vice-versa for set only functions. The major use I can see is for data validation when setting class attributes, instead of having to check incoming data at multiple points in my ciode it can all be done in my set function within the class. Encapsulation is the whole point of OO programming, just like the construct and destruct functions the set and get are invaluable in OO design. As far as setting a variable from inside your code in the same class, you are the programmer and you have to make sure your data is valid for the target variable. Just as with the construct and destruct functions the zend engineers had a very good reason for making them part of the "magic functions".

I would have like to have seen the poll be a little bit more specific as in "Do you use generic or specific accessors in your classes?", since some people (like myself), dont always use "setWhatever" when the number of attributes in a class is variable, and prefer the generic accesor flavor ("getVar('name') / setVar('name', $value)").

Anyway, I answered it as "no", meaning "I don't use specific accessors all the time, but I do use generic accessors almost always". I guess I should have chosen "undecided"

Well the poll is only about whether you use getters and setters (generic or not) within the exact same class they belong to. The question was not what type of getters or setters you use (generic or not). It is a yes/no question.

Originally Posted by Dr Livingston

As for setter class methods, I don't bother, I set the class properties publically, which doesn't really matter in my view, as it happens in the lower layers anyway.

Not good IMO, what if you wanted to add a specified tax to an amount of a class? You would need to do that in the client code...probably a thousand times instead of only once in a setter.

Well IMO it's not only opinion, using generic setters you save a ton of code lines as you can simply copy the generic setters/getters into all classes where you need them allowing you to avoid writing a ton of setters/getters and that simply do the same job.

One real drawback is that if you change the name of an attribute you would change all client code that uses it, which is really bad. With normal setters/getters you stay independent. However, normally your attribute names do not change often...one often just removes or adds attributes.

class TimerTask
attr_reader :timer
def timer=(value)
value = value.to_i if value != nil and !value.is_a?(Integer) and value.respond_to?(:to_i)
raise "Time must be a valid timestamp" if !value.is_a? Integer
raise "Cannot set time in the past" if value <= Time.now().to_i
@timer = value
end
end

One real drawback is that if you change the name of an attribute you would change all client code that uses it, which is really bad. With normal setters/getters you stay independent. However, normally your attribute names do not change often...one often just removes or adds attributes.

I suppose you could do that trick with a generic accessor aswell, although you may soon loose the overview if you do it too often.

A large part of this question is about Containers in general. In this very long and inconclusive thread I came to the conclusion that the answer is different for PHP4, PHP5 and (hopefully PHP6). For PHP4, the $obj->set($key, $value) may be necessary and is certainly easier (and more PHPlike because it is "stringy"). In PHP5 you can almost pull off $obj->key = $value or $obj->setKey($value), but because the __set() and __call() functions are error handlers and not true property handlers you still have the problem with already defined properties. Hopefully PHP6 will add true property handlers.

I would say that using a generic Container as the basis for many appropriate classes can open up some interesting possiblities for using objects in ways you hadn't thought of before.

In PHP5 you can almost pull off $obj->key = $value or $obj->setKey($value), but because the __set() and __call() functions are error handlers and not true property handlers you still have the problem with already defined properties. Hopefully PHP6 will add true property handlers.

Not really true. In fact the current setter/getter system in PHP5 is quite flexible and I like it.

Bonefry, not to be offensive or anything, but could you please comment on your code a bit - what makes it so flexible? Most of us don't have the time to read through all code listings, understand them and elaborate on them.

Bonefry, not to be offensive or anything, but could you please comment on your code a bit - what makes it so flexible? Most of us don't have the time to read through all code listings, understand them and elaborate on them.

Thank you in advance.

Well, you should have the time. The code is easy enough to argument my point.

And my point is that you can replace current properties because that was the point of __set and __get in the first place -> to define property handlers and not properties.

Getters and Setters are Evil, morally objectionable behavior.

The get/set methods expose some of the implementation of the system, hiding implemenation leads for a good acid test of the quality of an OO system.
Don't ask for the information that you need to do some work, instead ask the object that has the information to do the work for you.

Think about coarse v fine grained operations.
Coarse-grained operation asks an object from a system to do a lot of work.
A fine-grained operation asks for only a small of work.
Generally coarse-grained operations/methods simplify the implemation code, eliminating the need for the get/set tER methods.

Not really true. In fact the current setter/getter system in PHP5 is quite flexible and I like it.

My point was neither that the PHP5 system was not flexible, nor that you or I or anyone else doesn't like it. My point was that because __get()/__set() are error handlers (called only when the property does not exist) rather than accessor handlers they are not a complete accessor solution.