PHP has a pretty basic class model. You can define classes and create methods as functions within the class. You can also define properties (aka attributes), although in a fairly loose and seemingly uncontrolled way. Users can instantiate the class and then get and set the properties as they wish.
However, I just read that it’s bad form to let users read and write to properties directly, as this should always been done through a method. That is to say rather than saying $myClass->email=\'admin@example.com\'; you should more properly do something akin to $myClass->setEmail(\'admin@example.com\');.
I guess that’s a sensible idea as PHP provides no inherent mechanisms for marshaling values in and out of the properties without resorting to using methods. It does nevertheless seem a little cumbersome to have to create a get and set method for every property. Blurgh.
Something else that’s getting on my tits today is the inability to directly set a property as the default value for an method attribute. That is to say, you can’t do this:
function sendEmail($email = $this->email){
// foo;
}
Instead, you have to something ugly like this:
function sendEmail($email = \'\'){
if (!$email){
$email = $this->email;
}
// foo;
}
This is less than ideal, and although it hasn’t quite spoiled my afternoon, it did make me growl at the wall for a bit. Ho hum. I’m sure it’s all positive really.
Comments
http://www.calvin.edu/archive/abstraction-chat/200302/0216.html
That’s a great article, and, if you plan on moving from PHP into Java, you should get used to getter and setter methods - that’s really the OO way to do things.
Welcome to the tedium that is the life of an object oriented developer ;-)
I would say I spend 90% in Java 10% in PHP and it’s frustrating, moving back to PHP and trying to write a class, only to realise the restrictions. Hopefully PHP5 will address this.
George
I find the limitations of PHP frustrating, but only because I like PHP so much. It’s so agile. I don’t get too frustrated about ASP because basically I couldn’t care less about it. I hate that PHP has no way to declare variables and will not error if you use a variable without declaring it first. It’s downright dangerous. It makes me nervous with every line of code I write.
You’re right .. I hope PHP5 is better.
I’m surprised that nobody else has pointed this out, but in the upcoming version 5, PHP’s object model is becoming quite a lot more robust and, dare I say, Java-like, which includes ”private” and ”protected” keywords, as well as ”type hinting” to restrict what sort of data which can be passed as an argument to a function.
Concerning getters and setters, I can’t fathom needing to write a getter and setter for every class variable, but in a language as dynamically-typed as PHP, I find that getters and setters are very useful for ”validating” what goes in and out of an object.
Try this:
error_reporting(E_ALL)E_ALL can also be set in your PHP config file (PHP.ini, or on a per-site basis using Apache config files).
$myvar = ”select id, username from accounts where date
G
You could try `overloading` , http://php.net/manual/en/language.oop5.overloading.php
For :
$myClass->email = ‘admin@example.com’;
you could do :
class A
…{
……public function __set ($name , $value)
………{
…………$this->$name = $value;
………}
…}
And for :
$myClass->setEmail( ‘admin@example.com’ );
you could do :
class A
…{
……public function __call ( $name , $arguments )
………{
…………$member = substr( $name , 3 );
…………switch ( substr( $name , 0 , 3 ) )
……………{
………………case ‘get’ :
……………………return $this->$member;
………………case ‘set’ :
……………………return $this->$member = $arguments;
……………}
………}
…}
With the e-mail thing , it might be less cumbersome when shorthand-notation is used ?
$email = isset( $email ) && !empty( $email ) ? $email : $this->email;
Or you might be looking for constants , as in :
class A
…{
……const b = ‘zzz’;
……public function c ($d = A::b)
………{
…………echo $d;
………}
…}
$e = new A;
$e->c();// Should display : zzz
Now you spoke of agile , I gave you the two solutions for this that were on the top of my head .
Ofcourse things should be handled more elegantly .
I can however barely decide which one of these two I would like to use in my code :
$myClass->email = ‘admin@example.com’;
$myClass->setEmail( ‘admin@example.com’ );
The first one is quicker , the second one gives the option of passing multiple arguments/parameters .
Maybe I could make a hybrid of them both , I will give it a try :
class A
…{
……private function genericSet ( $member , $arguments , $collected_arguments = FALSE )
………{
…………if ( $collected_arguments === TRUE)
……………{
………………if ( method_exists( $this , ‘set’ . $member ) )
…………………{
……………………return call_user_func_array(
………………………array(
…………………………$this
…………………………, ‘set’ . $member
………………………)
………………………, $arguments
……………………);
…………………}
………………else
…………………{
……………………$arguments = $arguments0;
…………………}
……………}
…………$this->$member = $arguments;
…………return (bool) ($this->$member === $arguments);
………}
……public function __call ( $name , $arguments )
………{
…………$action = substr( $name , 0 , 3 );
…………$member = substr( $name , 3 , 0 );
…………if ( $action === ‘set’ )
……………{
………………return $this->genericSet( $member , $arguments , TRUE );
……………}
…………elseif ( $action === ‘get’ )
……………{
………………return $this->genericGet($member);
……………}
…………return FALSE;
………}
……public function __set ( $name , $value )
………{
…………return $this->genericSet( $name , $value );
………}
……public function __get ( $name )
………{
…………return $this->genericGet( $name );
………}
…}
Ofcourse there could also be checked that the user of the class
does not try to set members that are not part of the class it’s blueprint .
(i.e. preventing the members to be automatically created)
Ofcourse there’s probably a lot more stuff as well ,
but this would probably be very workable …
I am sorry , I didn’t look at the date your post was from … : S
Since it’s been a while since then , you probably have found a way for this ,
you can forget about my post completely if you would like to . : )
And I ask you not to put this post (with my appology) on your blog at all .
Brief article but highlights a very good point that class methods should always be used for setting and getting class properties rather than direct access.
Good read.
Thanks,