SitePoint Sponsor |
|
User Tag List
View Poll Results: Do you use setters and getters to attributes of a class within that class?
- Voters
- 123. You may not vote on this poll
-
yes
58 47.15% -
no
38 30.89% -
undecided
12 9.76% -
what are you talking about? xD
15 12.20%
Results 76 to 93 of 93
-
Nov 4, 2005, 13:08 #76
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
-
Nov 4, 2005, 13:12 #77
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
The key difference between a->b->c and "doubleX" in my example is that get(c) doesn't run on the stack of get(b). At the moment when get(c) is called, get(b) is already completed, hence no "recursion". get(doubleX) invokes get(x), thus attempting to re-enter __get, which is forbidden. I don't think they're going to fix this (http://bugs.php.net/bug.php?id=30002), but who knows...
-
Nov 4, 2005, 13:34 #78
- Join Date
- Nov 2004
- Location
- Romania
- Posts
- 848
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stereofrog
Ouch, I never saw that coming .... god dammit .... to many bugs for my taste.
And no, it doesn't make the feature useless, because no one cares how the implementation is done as long as the interface just works ...
PHP Code:class B extends A {
function getX() { return 10;}
function getDoubleX() { return $this->getX() * 2; }
}
$b = new B;
echo $b->x; // this works
echo $b->doubleX; // this does too
And let me put it this way. If I have class B that has been used for quite some time, and I need to refactor the code so that I have setters/getters without direct access (whatever the reason), all I care about is to keep the following code working:
PHP Code:echo $b->x;
echo $b->doubleX;
Anyway, all these PHP bugs are getting pretty annoying.
-
Nov 4, 2005, 13:44 #79
- Join Date
- Nov 2004
- Location
- Romania
- Posts
- 848
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ah, great, interesting comments from that link - http://bugs.php.net/bug.php?id=30002
It is expected behavior because __get/__set have a simple recursion
protection which disables __get/__set during __get/__set calls.I really doubt that it's a bug because if we allow calling __get() from
__get() you'll get into endless loop easily, which is of course much
worse than just a notice.Have I told you guys how much I love PHP ?
-
Nov 4, 2005, 14:05 #80
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by bonefry
-
Nov 4, 2005, 14:53 #81
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I've been rooting around in the internal property access code, I doubt the recursion will be turned off. I have no special knowledge on this, but I get the feeling __get and __set were added to support proxy objects, which they are more than adequate for, rather than to support domain object accessor methods, a task which for which they fall short.
I also hate the "overloading" terminology. Its incredibly confusing. I also don't like when __get and __set are called accessor methods. The terminology I prefer is property not found handler.
-
Nov 4, 2005, 15:55 #82
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stereofrog
Interesting comment: http://bugs.php.net/bug.php?id=29070
Originally Posted by derick at php.net
Hello World
-
Nov 4, 2005, 16:21 #83
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
-
Nov 6, 2005, 01:40 #84
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Anybody using getVar('name') / setVar('name') who's running php5 needs to be kicked in the head.
Using getters / setters on internal properties usually smacks of someone who's spent way too much time in school and not enough actually developing applications that people use.
-
Nov 6, 2005, 01:55 #85
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stereofrog
Arguing over whether or not __get and __set are an ideal solution, perfectly implemented, or anything else is kind of silly. They work quite well for what they were intended for, and they make many tasks a whole lot simpler (especially when dealing with objects that mostly just store data). If you don't like how they were implemented, either don't use them, or come up with a better solution and submit the patch.
I generally argue that using __set (or set('name',$Val) or setName($Val)) is most often indicative of a class attribute that shouldn't exist in the first place. If you're allowing outside objects to arbitrarily change the value of some object setting (other than perhaps to flip switches or the like) on the fly, you should REALLY think about whether or not you're actually implementing it right in the first place. If you're thinking it'll make it easier to refactor later, you're wrong. Stuff like this will require changing much more than a few accessor calls. All it takes is somebody accidentailly doing (if($Obj->Data = null)) and you've got yourself a guaranteed bug.
__get is extremely useful when you want to implement read-only properties (for preventing coding mistakes, because you can't ever ACTUALLY enforce stuff like this when other people have access to the source).
-
Nov 6, 2005, 02:14 #86
Here's an example of two classes using __get/__set, I'm realy starting to like the $_ aproach
.
PHP Code:<?php
class A{
protected $_name;
public function __get($var){
$method = 'get'.ucfirst($var);
return $this->$method();
}
public function __set($var,$val){
$method = 'set'.ucfirst($var);
return $this->$method($val);
}
protected function getName(){
return $this->_name;
}
protected function setName($val){
$this->_name = $val;
}
}
class B{
protected $a;
protected $_vector;
public function __construct(){
$this->a = new A;
}
public function __get($var){
$method = 'get'.ucfirst($var);
return $this->$method();
}
public function __set($var,$val){
$method = 'set'.ucfirst($var);
return $this->$method($val);
}
protected function getAname(){
return $this->a->name;
}
protected function setAname($val){
$this->a->name = $val;
}
protected function setVector($val){
$this->_vector = $val;
}
protected function getVector(){
return $this->_vector;
}
}
$b = new B;
$b->Aname = "thr";
echo $b->Aname;
$b->vector = array();
$b->vector[0] = "thr";
var_dump($b->vector);
?>
-
Nov 6, 2005, 02:26 #87
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
In fact, I'd suggest that the kung fu coders possibly ought to spend some more time at school. Mock objects might make some interesting reading.
-
Nov 6, 2005, 15:21 #88
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
Please spend some time meditating on this http://www.sitepoint.com/forums/show...3&postcount=17
-
Nov 7, 2005, 02:28 #89
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
Stereo: I'll stand by that forever, just like I would if we were talking about MySQL, Linux, Apache, or any other open-source project. If you don't like what the open-source product offers, and you aren't willing to submit your own code, then maybe you should consider using a proprietary solution. Of course, with properietary software the only answer to the problem is "don't use it". A feature or fix not implemented the way you would like it to be doesn't constitute a bug. A bug is when something doesn't behave the way it was intended to. With open source, you have a solution: implement it the way you'd like it to be implemented. The feature has been extremely useful to a great many people using PHP5, myself included. Could it be better? Probably, but that doesn't mean that:
1.) Changes should be made automatically (decisions about BC, forward compatability, consistency, etc. all have to be taken into account)
2.) It should get high priority (security vulnerabilities are always #1, then major bugs, then new, useful features, and lastly small tweaks and minor bug fixes that benefit a small percentage of users).
Also, if you're going to argue that Zend specifically should take responsibility for it, why not ask the same of Yahoo? Yahoo contributes a whole lot of man power to the PHP project, and is far and away the web company that makes the most extensive use of the software. Their programmers have been responsible for introducing bugs (and fixing them), adding new features (and breaking others), and changing behaviors radically. Arguing that Zend should be held accountable for PHP is like arguing that Novell be held accountable for Linux. There is only one group that can be held accountable for PHP, and that's the PHP developers -- which means a collection of mostly volunteers, sprinkled with a few developers working for companies who benefit by making the project better (and are effectively giving the fruits of their labor to the community at no charge).
The companies I work for (and myself, personally) have never paid Zend one cent, and yet we've made a small fortune off of PHP. What possible justification could we have for holding them accountable for a bug in code that they didn't even write (and, indeed, may not even be aware of?) There are thousands upon thousands of companies out there making their living off of PHP, and if it's anyone's responsibility to make sure that problems get resolved, it's those people and companies.
I've said this numerous times, and I'll repeat it here: If you don't like it, change it, use something else, or just live with it. If you're already using something else, then why are you here in the first place? If you're continually finding that PHP isn't helping you solve problems, then why are you using it?
-
Nov 7, 2005, 17:59 #90
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
-
Nov 7, 2005, 18:52 #91
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
As for the whole "I'm in a position to kick people in the head" thing ... baffling ...Christopher
-
Nov 11, 2005, 06:57 #92
- Join Date
- May 2004
- Location
- Netherlands
- Posts
- 219
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Scheisskopf
Of course since most projects are for personal (one functional) use only, you wouldn't suffer from this much ... Nevertheless, there is a point to making variables private (Java style) and thus using get/set methods!
Quaint Tech - Blog on web development and web technology.
-
Mar 1, 2006, 19:43 #93
- Join Date
- Aug 2005
- Location
- The Czech Republic
- Posts
- 25
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Property setters and getters - final solution
Bookmarks