Static properties View as Markdown

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:

...

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