Re: Concerns over handling of bug #49105

Hey, I have a mixed background with a heavy focus on PHP both procedural and OO in fact. But that is not the point here. The concern over PHP apps from 4.0.0 seems a bit of a stretch for a number of reasons: First off being that PHP 5 OO is vastly improved over 4. Second that the fix would simply be to add self:: to the references. Third, the implied design at present is disingenuous. Fourth changes have been made that impact versions in the past. Although PHP has been *good* to its legacy apps, I can't imagine future development and improvements being so restricted. Especially ones that involve correcting default behaviour **which may have entrenched themselves without merit**. This problem may have arisen organically and the implications were never considered, so why not consider it now? The assumption that there is no benefit is not really truthful. If another language like Java saw fit to implement this (I didn't know it did!), then there obviously is merit. There's some pretty good advantages when it comes to writing reflective superclasses. I'll address your "solutions", which really do not address *my* issue, but instead redefine my problem: 1) I want each child to have their own copy of the variable. 2) Static __get and instance __get *are* what I am using, but without a unique copy of the variable, all subclasses end up storing their unique information in the parent class. You have just proven one of the design limitations here. 3) Not an option, my users need to be able to inherit from the superclass without having to know its internals. This seems obtrusive as I am not writing the subclasses, I am only writing an abstract parent class... Given that you're trying to rationalize the "bogusing" of this bug, maybe I can put forward another idea. I understand the legacy concern, I truly do. Although at some point, PHP itself has even resigned itself to locking certain features to a particular version of the engine. BUT! In other cases, PHP has introduced new constructs (rather than alter default behaviour) so that the new behaviour can be accomodated. Is there not a way to perhaps suggest introducing a "copied" keyword or a new modifier *similar* to protected, but that triggers a copy of each property in a subclass? Something like: protected copied static $property = null; You guys may at this point be better suited to come up with a proper name, but at least at that point the thought is getting consideration. This is similar to the approach that late static binding took which was not to alter default behaviour, but to allow for behaviour to be further specified. Which is much more in the spirit of PHP's very generic nature... I don't think this is something that PHP should be guaranteed to never have. Similar to how it was almost assumed that it would never have late static binding...Which we can see obviously is just not the case. I get what YOU mean, but do you get what I mean? - Alex On Thu, Jul 30, 2009 at 4:06 PM, Greg Beaver <greg@chiaraquartet.net> wrote: > Alexander Trauzzi wrote: > > > The three scopes self::, static:: and parent:: allow for this to be > > explicit. Why deny them their implied use? Why would any class even > want > > to refer to the parent property as a default when the static:: scope is > > used? It's already saying "I want this in a runtime scope, not load > time." > > > > The two questions are: > > > > 1. Why wouldn't PHP want to duplicate properties in subclasses? Again, > > especially given the abundance of useful scopes like parent:: static:: > and > > self::. > > This is how Java works, perhaps you are coming from that background? > > > 2. Why would a call to a static::$property fall through to the parent > class? > > The same reason that a call to $this->property falls through to the > parent class: because that is the way PHP was designed. > > Changing this would literally break every single existing OOP > application written since PHP 4.0.0 was released. Want an example? > Pyrus (see http://pear2.php.net) stores its configuration using > a Config > class, and also has the ability to store a snapshot of a configuration > and to use that. The Config\Snapshot class needs to be able to use the > parent variables, but overrides the way they are handled by extending a > few methods. > > What everyone is trying to tell you is that this is a core design > element of the language, and changing it would wreak havoc for no benefit. > > If you want to hide a variable from a child class, you have several > options in PHP. > > 1) private. Declare the variable as private, and the child class will > not access the parent variable. > 2) __get()/__static_get(). Implement __get()/__static_get() > 3) require your users to define any static variables they want to handle > differently, and use self:: to access them. static:: is explicitly > designed to provide polymorphism for static variables, something we > already get for class properties > > In short, the reason this bug was "bogus"ed was because it is simply not > even possible to consider changing this - it would be like suggesting > that PHP change all variable names so that they must start with # - it's > not going to happen, ever. > > Greg > -- _________________________________________________ Alexander Trauzzi