# Static properties

- Thread: https://externals.io/message/22954
- Original archive: https://news-web.php.net/php.internals/22954
- Started by Edin Kadribasic on 2006-04-25T11:30:28+00:00
- Messages: 15
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #22954 — Edin Kadribasic — 2006-04-25T11:30:28+00:00

URL: https://externals.io/message/22954#22954

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

---

## #22956 — Petar Nedyalkov — 2006-04-25T13:02:39+00:00

URL: https://externals.io/message/22954#22956 · In reply to: #22954

> 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

---

## #22957 — Jochem Maas — 2006-04-25T13:15:52+00:00

URL: https://externals.io/message/22954#22957 · In reply to: #22956

Petar Nedyalkov wrote:
> 
> 
> > […]
> 
> 
> 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. :-)

> 
> 
> > […]

---

## #22958 — Edin Kadribasic — 2006-04-25T13:20:55+00:00

URL: https://externals.io/message/22954#22958 · In reply to: #22956

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

---

## #22976 — Marcus Boerger — 2006-04-26T19:15:37+00:00

URL: https://externals.io/message/22954#22976 · In reply to: #22957

Hello Jochem,

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

> Petar Nedyalkov wrote:
> > […]

> 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. :-)

> > […]

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

Best regards,
 Marcus

---

## #22981 — Jochem Maas — 2006-04-26T19:39:40+00:00

URL: https://externals.io/message/22954#22981 · In reply to: #22976

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:
> 
> 
> > […]

...

> 
> 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 :-)

> 
> > […]
> 
> 
> 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 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

---

## #22980 — Edin Kadribasic — 2006-04-26T20:59:56+00:00

URL: https://externals.io/message/22954#22980 · In reply to: #22976

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

---

## #22991 — Marcus Boerger — 2006-04-27T13:19:48+00:00

URL: https://externals.io/message/22954#22991 · In reply to: #22980

Hello Edin,

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

> Marcus Boerger wrote:
> > […]

> 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

---

## #22992 — Marcus Boerger — 2006-04-27T13:22:21+00:00

URL: https://externals.io/message/22954#22992 · In reply to: #22981

Hello Jochem,

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

> Marcus Boerger wrote:
> > […]

> hi Marcus,

> > […]

> 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.

> > […]

> '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.

> > […]

> many thanks for your clarification.

no problem

Best regards,
 Marcus

---

## #22993 — Edin Kadribasic — 2006-04-27T14:35:39+00:00

URL: https://externals.io/message/22954#22993 · In reply to: #22991

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.

> > […]
>
> 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

---

## #23089 — Marcus Boerger — 2006-05-02T20:22:53+00:00

URL: https://externals.io/message/22954#23089 · In reply to: #22993

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:
> > […]

> 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.

> > […]

> 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

---

## #23120 — Derick Rethans — 2006-05-03T11:29:54+00:00

URL: https://externals.io/message/22954#23120 · In reply to: #23089

>   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

---

## #23243 — Derick Rethans — 2006-05-11T12:17:57+00:00

URL: https://externals.io/message/22954#23243 · In reply to: #22980

> Marcus Boerger wrote:
> > […]
> 
> 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

---

## #23250 — Andi Gutmans — 2006-05-11T14:29:15+00:00

URL: https://externals.io/message/22954#23250 · In reply to: #23243

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:
>
>
> > […]
> should be a
> > […]
> discussion about
> > […]
> and more Java
> > […]
> impossible.
> > […]
> having such
> > […]
>
>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

---

## #23251 — Derick Rethans — 2006-05-11T14:33:00+00:00

URL: https://externals.io/message/22954#23251 · In reply to: #23250

> 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