Wed 4 Jan 2006
Get it? Set it? Good!!
Posted by nola under PHP
I don’t know where this idea settled into my little head, probably back in college. I sold practically every book from my college days, keeping only a few books (For anyone who had a blue book by Blum with a picture of driftwood on it for Software Engineering, you have my sypathies. Can’t believe its still $97 bucks) so I can’t look back to see if any of my classes was the culprit (could it be java? it sure wasn’t assembler!). I have always defined get/set methods for my classes with get/set in the name.
class Card {
var $name;
function set_name($name = "") {
$this->name = $name;
}
function get_name() {
return $this->name;
}
// etc
}
I’ve seen some people do this:
class Card {
var $name;
function name($name = "") {
if (empty($name)) {
return $this->name = $name;
} else {
$this->name = $name;
}
}
// etc
}
Using the same method for getting or setting, the deciding factor is if a parameter is passed.
I mentioned this in a Codesnipers post about how Ruby does get/set for attributes. Caleb Tennis showed a way I could customize the get/set methods of Ruby so it DOES allow you to do getName or setName.
My recent language crush is Perl, and I’ve seen many modules doing it the second way.
But “name” isn’t a function so I don’t really like doing it the second method. But is it an “okay” convention that I should wave a white flag and accept? I guess I could look at it this way, if a function name is just a noun, then it’s for an get/set method, if not then it’s a regular method.
Should I change my mind on this? what do you do?
January 5th, 2006 at 12:36 am
I’ve seen coherent arguments for getters that double as setters vs having separate getters and setters.
My thought is that I prefer separate names, because I’ve wanted to grep my source code for all setters, for example, and having a separate name is handier for that. Also it avoids the problem of a read-only getter silently ignoring an attempt to set something, which is a very real problem.
January 30th, 2006 at 1:14 pm
I think you may have a bug in your Card::name() function.
——8name = $name;
——8name(”); to clear the name. it would return the value of name instead. Instead, I’d have the $name parameter be NULL if omitted and check for is_null(). It’s a little bit more specific, but again, you won’t be able to do: $card->name(NULL); If you’re mapping classes to database tables, it would be hard to make the distinction between empty strings and NULL if that’s something your business logic pays attention to.
January 30th, 2006 at 7:40 pm
I see what you mean Lucidix. I hadn’t actually tested that code, just hammered it out an an example. Using Null is good, I’ve been using it the past few days instead of “”
thanks for commenting!