Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49440
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Ferenc Kovacs <info@tyrael.hu>
Cc: RQuadling@googlemail.com, Jingcheng Zhang <diogin@gmail.com>, php-dev <internals@lists.php.net>
In-Reply-To: <AANLkTikwOkJyCkw89DbNYpb4cV_mX39s6mL0FMxqK2bS@mail.gmail.com>
References: <AANLkTimpbdUxWP0H1brKBzv9Ub5QKEm=UGaa_XDGB8dG@mail.gmail.com>
	 <AANLkTikz2r3-ukyJfSLJDAV04wgq=a7QD_+SgfDn7Krd@mail.gmail.com>
	 <AANLkTikwOkJyCkw89DbNYpb4cV_mX39s6mL0FMxqK2bS@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 17 Aug 2010 16:58:48 +0200
Message-ID: <1282057129.1073.61.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Static initialization block support in Class?
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Tue, 2010-08-17 at 10:46 +0200, Ferenc Kovacs wrote:
> > > I wonder whether it is possible to implement "static initialization
> > block"
> > > feature in PHP, for example:

As PHP allows code in the global scope I don't think this feature is
really needed. Especially as it has some potential conflicts when
defining the time by which it should be executed. You need all class
binding to be done when this static method is run, but in some cases we
delay the binding, so this won't be called when the class file is loaded
or we'd change some logic there. Simply using the global scope has an
already defined behavior.

> This was brought up in the past:
> http://www.mail-archive.com/internals@lists.php.net/msg46458.html
> I still think that it's weird, that I can define a constant to a dynamic
> value (eg. by a complex expression or a function's return value), but I
> can't do that with the class consts. and with 5.3, we have two different
> kind of consts, you can define constants in compile time with const where
> you can't use expressions, and you can use the define method, where you can
> use expressions.

Well, the last time this was discussed I provided some pointers which
allow implementing this. The big issue is storing the code which shall
be executed.
The current way is that we store a name of a constant and resolve it
once it is needed the first time.
The most simple thing one might do, to extend this, is is to store an
OpArray for each constant. Depending on the changes done to the parser
this allows arbitrary statements with very little actual work needed,
but that's really messy in the result.
With this it can be really tricky to handle some errors, like recursion.
As long as we do a simple lookup this can be discovered quite easily.
("Fatal error:  Cannot declare self-referencing constant") With
arbitrary expressions you could trigger recursion in a way the engine
can't handle easily and where a user won't expect it (echo Foo::BAR; -
who would expect this to cause recursion?)

But well, feel free to implement it and play with it, maybe this all is
better than I think ... given the pointers from my previous mail and
some basic knowledge of the engine it should not take more than a day to
write a simple patch which allows experimenting.

johannes