Everything

php

Static properties

php.internals

Edin Kadribasic

20 years ago

Hi,

I was wondering if someone could enlighten me why it is not possible to
create on-the-fly static properties:

php -r 'class foo{}; foo::$bar = 1;'
Fatal error: Access to undeclared static property:  foo::$bar in Command
line code on line 1

Was this not possible because of the engine implementation of the static
properties?

Edin

Petar Nedyalkov

20 years ago

On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:

> Hi,
>
> I was wondering if someone could enlighten me why it is not possible to
> create on-the-fly static properties:
>
> php -r 'class foo{}; foo::$bar = 1;'
> Fatal error: Access to undeclared static property:  foo::$bar in Command
> line code on line 1

This totally breaks the capsulation in the OO paradigm, so I find it the right
behaviour. Taking apart the fact that there's no compilation in PHP, it also
prevents capsulation and making a member variable of an object available only
after it's declaration in the class (except for stdClass) is correct for me.
I see this as "You can't redefine the model at runtime".

>
> Was this not possible because of the engine implementation of the static
> properties?
>
> Edin

--

Cyberly yours,
Petar Nedyalkov
Devoted Orbitel Fan :-)

PGP ID: 7AE45436
PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc
PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Jochem Maas

20 years ago

Petar Nedyalkov wrote:

> On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:
>
>>Hi,
>>
>>I was wondering if someone could enlighten me why it is not possible to
>>create on-the-fly static properties:
>>
>>php -r 'class foo{}; foo::$bar = 1;'
>>Fatal error: Access to undeclared static property:  foo::$bar in Command
>>line code on line 1
>
>
> This totally breaks the capsulation in the OO paradigm, so I find it the right
> behaviour. Taking apart the fact that there's no compilation in PHP, it also
> prevents capsulation and making a member variable of an object available only
> after it's declaration in the class (except for stdClass) is correct for me.
> I see this as "You can't redefine the model at runtime".

Rubys allows exactly that and I'm sure your not going to say that Ruby is not an OO
language - Javascript likewise, in that it allows runtime definition/extension of
the model (granted it's prototype based rather than class based).

(anyone with the argument that PHP!=Ruby or PHP!=Javascript might consider that
PHP!="the OO paradigm")

I don't think the Fatal Error mentioned above is, from a endusers' POV,
what would be expected given the ability to define non-static properties on the fly...
If I had to guess as to what kind of error was raised I would have put my money on
E_STRICT - i.e. 'we don't recommend this way of doing things, but it doesn't hurt the
engine per se'

having said that I have never needed to define static properties on the fly, so it's
all rather academic. :-)

Marcus Börger

20 years ago

Hello Jochem,

Tuesday, April 25, 2006, 3:15:52 PM, you wrote:

> Petar Nedyalkov wrote:
>> On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:
>>
>>>Hi,
>>>
>>>I was wondering if someone could enlighten me why it is not possible to
>>>create on-the-fly static properties:
>>>
>>>php -r 'class foo{}; foo::$bar = 1;'
>>>Fatal error: Access to undeclared static property:  foo::$bar in Command
>>>line code on line 1
>>
>>
>> This totally breaks the capsulation in the OO paradigm, so I find it the right
>> behaviour. Taking apart the fact that there's no compilation in PHP, it also
>> prevents capsulation and making a member variable of an object available only
>> after it's declaration in the class (except for stdClass) is correct for me.
>> I see this as "You can't redefine the model at runtime".

> Rubys allows exactly that and I'm sure your not going to say that Ruby is not an OO
> language - Javascript likewise, in that it allows runtime definition/extension of
> the model (granted it's prototype based rather than class based).

Do not mix class based OO like PHP and prototype based OO like JavaScript.

> (anyone with the argument that PHP!=Ruby or PHP!=Javascript might consider that
> PHP!="the OO paradigm")

PHP simply supports its own set and view of OO.

> I don't think the Fatal Error mentioned above is, from a endusers' POV,
> what would be expected given the ability to define non-static properties on the fly...
> If I had to guess as to what kind of error was raised I would have put my money on
> E_STRICT - i.e. 'we don't recommend this way of doing things, but it doesn't hurt the
> engine per se'

> having said that I have never needed to define static properties on the fly, so it's
> all rather academic. :-)

>>
>>
>>>Was this not possible because of the engine implementation of the static
>>>properties?
>>>

It is just some decision that was taken that the newer OO stuff should be a
bit more strict.

Best regards,
Marcus

Edin Kadribasic

20 years ago

Marcus Boerger wrote:

> It is just some decision that was taken that the newer OO stuff should be a
> bit more strict.

I don't remember any such decision. I don't even remember a discussion
about it. I'm aware of the efforts of some people to make PHP less PHP
and more Java and thus we end up in a situation where:

class foo{}; foo::$bar = 1;

is a fatal error. This makes things that I really like about PHP
impossible. By now I'm used to being not constrained by a static
language and having such restrictions placed on new features makes no
sense to me.

I write code that does things like this:

class Customer
{
function get($id)
{
$res = $DB->query("select * from customer where id=".((int)$id);
while ($row = $DB->fetchRow($res)) {
foreach ($row as $key = $value) {
$this->{$key} = $value;
}
}
}
}

All nice and dynamic. Now, I thought why not make my site options work
in a similar way but use class variables (a.k.a. static properties). So
I made my options class

class options
{
function load()
{
$res = $DB->query("select * from options");
while ($row = $DB->fetchRow($res)) {
self::${$row['KEY']} = $row['VALUE'];
}
}
}

so I could for example througout my code use simple:

if (options::$allow_anon) {
...
}

without having to make an istance of the class. Simple and beutiful PHP
way. All I needed to do to get a new site option variable was to insert
"into options(key, value) values ('foo', 'bar')" and I would instantly
have my options::$foo.

Unfortunately I was faced with a fatal error about having to declare all
static properties. I was afraid that this was not caused by any
technical difficulty, but by desire to make PHP less PHP.

I propose that we remove this restriction in PHP 5.2.0 and that we
consider this attitude towards making PHP more strict and less dynamic
in the future.

Edin

Marcus Börger

20 years ago

Hello Edin,

Wednesday, April 26, 2006, 10:59:56 PM, you wrote:

> Marcus Boerger wrote:
>> It is just some decision that was taken that the newer OO stuff should be a
>> bit more strict.

> I don't remember any such decision. I don't even remember a discussion
> about it. I'm aware of the efforts of some people to make PHP less PHP
> and more Java and thus we end up in a situation where:

There was no endless discussion like we to often do on the list but instead
it was just something we came to agree upon among those implementing it
while implementing it.

> class foo{}; foo::$bar = 1;

To cut the story short, any feature might have an advantage for somebody but
also a heavy disadvantage for somebody else. But in the end if we'd agree to
add this feature we#d also end up in supporting interception of static
properties which we probably do not want.

Best regards,
Marcus

Edin Kadribasic

20 years ago

Hi Marcus,

Marcus Boerger wrote:

> There was no endless discussion like we to often do on the list but instead
> it was just something we came to agree upon among those implementing it
> while implementing it.

In other words there was no public discussion whatsoever ;)

Well since we're are talking about the future direction of PHP, I guess
the question deserves some attention. I strongly disagree with this
approach of making PHP more "strict" and static. I really liked its
dynamicity and would not like to see it disappear under the pressure
from people who think Java or C++ (or any other langauge) are cool. For
me *PHP* is the cool language.

I would really like to hear what do PHP group members/core developers
think about this.

>>class foo{}; foo::$bar = 1;
>
> To cut the story short, any feature might have an advantage for somebody but
> also a heavy disadvantage for somebody else. But in the end if we'd agree to
> add this feature we#d also end up in supporting interception of static
> properties which we probably do not want.

Mike has already demonstrated that the patch to implement this
particular feature is very simple:
http://dev.iworks.at/PATCHES/dyn_static.txt

Edin

Marcus Börger

20 years ago

Hello Folks,

Edin and me discussed the issue a bit more in detail and shared memories
of discussions from the original php 5.0 development. As a conclusion we
came to the idea that we should revive the idea of a 'strict flag' that
decides whether member variables (both static and non static) can be added
on the fly by simply using them or not. This would for example look like
this:

strict class FooBar
{
}
$obj = new FooBar;
$obj->baz = 1;      // E_ERROR (a fatal non recoverable error level)

class MyConfig
{
}
MyConfig::$allow_public_access = 1; // works pretty well

Both of us thought this would be a great solution and should suit everybody
in the php world. Also the possible slowdown would be not measurable since
it is only a single integer check that in some cases won't have and
influence on runtime at all.

Any thoughts? Anybody?

best regards
marcus


Thursday, April 27, 2006, 4:35:39 PM, you wrote:

> Hi Marcus,

> Marcus Boerger wrote:
>> There was no endless discussion like we to often do on the list but instead
>> it was just something we came to agree upon among those implementing it
>> while implementing it.

> In other words there was no public discussion whatsoever ;)

> Well since we're are talking about the future direction of PHP, I guess
> the question deserves some attention. I strongly disagree with this
> approach of making PHP more "strict" and static. I really liked its
> dynamicity and would not like to see it disappear under the pressure
> from people who think Java or C++ (or any other langauge) are cool. For
> me *PHP* is the cool language.

> I would really like to hear what do PHP group members/core developers
> think about this.

>>>class foo{}; foo::$bar = 1;
>>
>> To cut the story short, any feature might have an advantage for somebody but
>> also a heavy disadvantage for somebody else. But in the end if we'd agree to
>> add this feature we#d also end up in supporting interception of static
>> properties which we probably do not want.

> Mike has already demonstrated that the patch to implement this
> particular feature is very simple:
> http://dev.iworks.at/PATCHES/dyn_static.txt

> Edin

Best regards,
Marcus

Derick Rethans

20 years ago

On Tue, 2 May 2006, Marcus Boerger wrote:

>   Edin and me discussed the issue a bit more in detail and shared memories
> of discussions from the original php 5.0 development. As a conclusion we
> came to the idea that we should revive the idea of a 'strict flag' that
> decides whether member variables (both static and non static) can be added
> on the fly by simply using them or not. This would for example look like
> this:
>
> strict class FooBar
> {
> }
> $obj = new FooBar;
> $obj->baz = 1;      // E_ERROR (a fatal non recoverable error level)
>
> class MyConfig
> {
> }
> MyConfig::$allow_public_access = 1; // works pretty well
>
> Both of us thought this would be a great solution and should suit everybody
> in the php world. Also the possible slowdown would be not measurable since
> it is only a single integer check that in some cases won't have and
> influence on runtime at all.
>
> Any thoughts? Anybody?

I would like this too.

Derick

Derick Rethans

20 years ago

On Wed, 26 Apr 2006, Edin Kadribasic wrote:

> Marcus Boerger wrote:
> > It is just some decision that was taken that the newer OO stuff should be a
> > bit more strict.
>
> I don't remember any such decision. I don't even remember a discussion about
> it. I'm aware of the efforts of some people to make PHP less PHP and more Java
> and thus we end up in a situation where:
>
> class foo{}; foo::$bar = 1;
>
> is a fatal error. This makes things that I really like about PHP impossible.
> By now I'm used to being not constrained by a static language and having such
> restrictions placed on new features makes no sense to me.

Yup, I agree. OO is good, but it shouldn't limit application development
just for the sake of things not being pure OO.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Andi Gutmans

20 years ago

Yep I agree but unfortunately it seems that most people on the dev
team either don't care or don't speak up.
Also, I asked time and again to add BC breaking changes to an
UPGRADING file. Had that been done we would have noticed and could
have reacted.


At 05:17 AM 5/11/2006, Derick Rethans wrote:

Derick Rethans

20 years ago

On Thu, 11 May 2006, Andi Gutmans wrote:

> Yep I agree but unfortunately it seems that most people on the dev team either
> don't care or don't speak up.
> Also, I asked time and again to add BC breaking changes to an UPGRADING file.
> Had that been done we would have noticed and could have reacted.

Huh? This particular part was never changed as it was never
implemented...

regards,
Derick

Jochem Maas

20 years ago

Marcus Boerger wrote:

> Hello Jochem,

hi Marcus,

thanks for your response (It remains a bit of a honour when
someone from the dev ranks takes time to give feedback -
new insight often follows as secondary benefit).

>
> Tuesday, April 25, 2006, 3:15:52 PM, you wrote:
>
>
>>Petar Nedyalkov wrote:
>>
>>>On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:
>>>
>>>

...

>
> Do not mix class based OO like PHP and prototype based OO like JavaScript.

agreed - my point was more that to speak of 'the OO paradigm' might be considered
rather useless considering the disparity of paradigms that exist in the myriad
of 'OO' languages out there (I named scripting languages because thats all I
really know :-)

>
>>(anyone with the argument that PHP!=Ruby or PHP!=Javascript might consider that
>>PHP!="the OO paradigm")
>
>
> PHP simply supports its own set and view of OO.
>

indeed, which is more than fair, but I doubt you would deny that the 'set/view'
you speak of is set in stone - then goals post do move now and again because of
new developer wishes and/or insights into usage in the real world.

...

>
>>>
>>>>Was this not possible because of the engine implementation of the static
>>>>properties?
>>>>
>
>
> It is just some decision that was taken that the newer OO stuff should be a
> bit more strict.

'a bit'? ;-) that said your answer is honest and to the point and makes the
position of the devs clear - which is a good thing - knowing exactly what kind of
dogfood is on offer allows for informed decision by the user.

I realise that it must be difficult to strike a balance between those that
strive to drive the language to ever greater heights of <buzzword>enterprise-readiness</buzzword>
and the lower echalons that protest/struggle against/with the increasing
strictness of the language. (personally I find myself in between ... and sometimes
finding it hard to keep my existing code compliant :-)

>
> Best regards,
>  Marcus

many thanks for your clarification.

rgds,
Jochem

Marcus Börger

20 years ago

Hello Jochem,

Wednesday, April 26, 2006, 9:39:40 PM, you wrote:

> Marcus Boerger wrote:
>> Hello Jochem,

> hi Marcus,

>>>(anyone with the argument that PHP!=Ruby or PHP!=Javascript might consider that
>>>PHP!="the OO paradigm")
>>
>>
>> PHP simply supports its own set and view of OO.
>>

> indeed, which is more than fair, but I doubt you would deny that the 'set/view'
> you speak of is set in stone - then goals post do move now and again because of
> new developer wishes and/or insights into usage in the real world.

It turned out that nothing really is set in stone in PHP.

>>
>>>>
>>>>>Was this not possible because of the engine implementation of the static
>>>>>properties?
>>>>>
>>
>>
>> It is just some decision that was taken that the newer OO stuff should be a
>> bit more strict.

> 'a bit'? ;-) that said your answer is honest and to the point and makes the
> position of the devs clear - which is a good thing - knowing exactly what kind of
> dogfood is on offer allows for informed decision by the user.

> I realise that it must be difficult to strike a balance between those that
> strive to drive the language to ever greater heights of
> <buzzword>enterprise-readiness</buzzword>
> and the lower echalons that protest/struggle against/with the increasing
> strictness of the language. (personally I find myself in between ... and sometimes
> finding it hard to keep my existing code compliant :-)

balance is the keyword here.

>>
>> Best regards,
>>  Marcus

> many thanks for your clarification.

no problem

Best regards,
Marcus

Edin Kadribasic

20 years ago

Petar Nedyalkov wrote:

> This totally breaks the capsulation in the OO paradigm, so I find it the right
> behaviour.

This is PHP we're talking about. If you want 100% purist "capsulation"
according to "OO paradigm" you're clearly using the wrong language. Heck
even wrong language class.

What I wanted to know is if this limitation was the result of the
implemetation difficulty in the engine, or someone else's purist OO views.

Edin