It's not a bad idea but usually having accessor and mutator methods are used to validate the data first before writing it to the properties. If you don't have validation, you might as well set them directly and make them public and don't really need a generic setter/getter method.
Although, this way, if you decide later on to add a specific getter/setter for validation you wont need to change the code that accesses the properties. So, this is a valid approach to save some time. i believe php should have something like that built in... In fact actionscript (flash) has quite a clever way of doing this: With public class A { public function A(){} protected var _b:String = ""; set function b(val:String):void { if (val.match(/([0-9])*/)) { _b = val; } } get function b():int { return int(_b); } // ... } you can write accessors and mutators which are pretty smart. With var instance:A = new A(); instance.b = "1234"; you will call the set method and let it validate a string to be a number only string, so _b can only be set to a string with only numbers. I found that very neat in actionscript because instead of writing instance.setB("1234"); you simply write instance.b = "1234"; and yet you get the benefit of validation. Then it is safe in the getter method to return an integer (assuming the validation is right). Java (and a lot of other languages) seems a bit clumsy in that way to be honest although i like the language as such. A lot of frameworks and class diagram code generators generate the getter and setter methods for you, but if you look at the actionscript way, you see it's not really necessary. It just adds overhead. But actionscript just makes it short and you can safely make your members public until you provide a set method and then you wont have to change any of the code where you are setting (or getting) it, because it stays the same! Actionscript 3 has some very nice features like you can loosely type like in PHP but you can also give strict types like in Java, making it more flexible while still restrictive if necessary for stability. Maybe the PHP developers should think about giving optional return types with :String for example and get and set methods as in actionscript. ... I know PHP is not actionscript. But a famous German man who was criticised for changing his mind said: "Why should i keep to my old statement if my knowlege about the matter has improved?" (or similar..., sorry don't remember who). Optional return types wouldn't hurt performance wise would they? And also they wouldn't even change the current syntax! In fact, isn't everything strictly typed under the hood anyway? As far as i know, in php you can already strictly type function parameters as in: public function asd(string $mystr) { $this->hola = $mystr; } Why not make it complete? Or is it? Sorry for stealing the thread. ;-) Also, i know php is an interpreted language. But wouldn't it be possible to write a virtual machine for php and compile byte code... I know, php is not Java or Actionscript :-P but it could be an add on feature. i guess the eval wouldn't work then would it? Although eval could still be interpreted... This would be nice in case you need to protect your intellectual property. Regards, Tim Tim-Hinnerk Heuer http://www.ihostnz.com Emo Philips - "I was the kid next door's imaginary friend." 2009/2/19 Philip Thompson <philthath...@gmail.com> > Hi all. > > Maybe I'm wanting more Java-like functionality out of PHP, but I don't > really like getting and setting members directly (even for public members) - > I'd rather use accessors. This way you can control what is getting set and > what is returning. However, I also don't really want to create a million > get/set accessor methods - this is no fun and takes up a lot of space. After > reading around a little bit, it got me thinking about overloading in PHP > (which I'm sure we all know is completely different than any other > language... but that's another day). I didn't want to use the standard __get > and __set methods because that still leaves me with the same notation for > getting/setting members. So, instead, I used a close relative of __get and > __set. Meet brother __call. Could it really be this trivial to get the > notation I'm wanting? Yes. Yes it is. Ok, enough talking... onto the code. > > <?php > class Person > { > public $age; > private $first, $middle, $last; > > // Gotta have our construct > public function __construct () {} > > // Here's the fun > public function __call ($member, $args) > { > // Since I know members I want, force the user to only > // access the ones I've created > if (property_exists ('Person', $member)) { > // If args is empty, I must be returning the value > if (empty ($args)) { > list ($value) = $this->$member; > return $value; > } > > // Oh, args is not empty! Set the value > $this->$member = $args; > } > else { > // Blow up! > die ("Fatal Error: Call to undefined member: $member. > Exiting..."); > } > } > } > > $person = new Person(); > > // Set the (private) first and last names > $person->first('Billy'); > $person->last('Bob'); > > // Get the (private) first and last names > echo $person->first() . " " . $person->last()."<br/>"; > > // Set the (public) age > $person->age(103); > > // Get the (public) age > echo "Age: ".$person->age()."<br/>"; > > // Explosions > $person->first = 'Buford'; > $person->pizza('Is yummy'); > ?> > > Now if you're reading this and thinking "Duh!" then good for you. However, > I know there's at least 1 soul on this list who may benefit from this. But > don't stop at the example above. If you want to add validation to the > members you're getting/setting, build that into your code. If you want each > member to be a specific type, include that as well (I'll leave the > implementation up to you). ;-) > > So let's recap. > > • This functionality allows me to not have to write 2 accessors for every > member > • This allows me to use methods instead of directly getting/setting > members (even though I can still access public members directly... if I > want) > • Keeps code consistent and less confusing - I know how to get and set > every member > > What are your thoughts? Does this seem like a reasonable implementation? > Useful? Pointless? Hit me up - I can handle *constructive* criticism. But > for now, it's late and past my bedtime. > > Cheers, > ~Philip > > "innerHTML is a string. The DOM is not a string, it's a hierarchal object > structure. Shoving a string into an object is impure and similar to wrapping > a spaghetti noodle around an orange and calling it lunch." > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >