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 <philthathril@xxxxxxxxx>
> 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
>
>
