Re: [PHP-DEV] New RFC : empty() function

[Kamil Tekiela]

Hi Alessandro,

I would still advise to just let this empty() construct die a natural
death.

If you want to change anything, you must remember that it's basically a
syntactic sugar for `@!$var`

For example if(empty($var)) is just if(@!$var)

To change this function would require changing the rules for type juggling.

Re: [PHP-DEV] New RFC : empty() function

[Alessandro Rosa]

Thank you, G.P.B. for editing and for sharing your honest viewpoint.
I saw your corrections and already fixed some flaws in the RFC text.

I raised issues that are critical on my modest viewpoint.
I see languages as an optimal mix between semantics, grammar and
performance.
The built-in empty() functions really needs to be revisited along these
directions.

Sincerely,

Alessandro Rosa


Il giorno mar 31 ott 2023 alle ore 12:34 G. P. B. 
ha scritto:

>
> On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa 
> wrote:
>
>> Hi Marcos,
>>
>> thanks for feedback.
>> Could you be clearer about your advice and gimme an example please?
>>
>
> I have edited the RFC content to add highlighting, hopefully you can now
> use that to improve the RFC text.
>
> However, I'm not very convinced at the moment that such a function is
> truly useful.
>
> Best regards,
>
> Gina/George P. Banyard
>
>
>
>

Re: [PHP-DEV] New RFC : empty() function

[G. P. B.]

On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa 
wrote:

> Hi Marcos,
>
> thanks for feedback.
> Could you be clearer about your advice and gimme an example please?
>

I have edited the RFC content to add highlighting, hopefully you can now
use that to improve the RFC text.

However, I'm not very convinced at the moment that such a function is truly
useful.

Best regards,

Gina/George P. Banyard

Re: [PHP-DEV] New RFC : empty() function

[Alessandro Rosa]

Hi Marcos,

thanks for feedback.
Could you be clearer about your advice and gimme an example please?

Alessandro

Il giorno mar 31 ott 2023 alle ore 11:59 Marcos Marcolin <
marcolin...@gmail.com> ha scritto:

> Hi Alessandro,
>
> It would be better to add syntax highlighting to the code examples of
> your RFC, it is not legal to read/understand the texts as if they were
> just texts.
>
> ---
> Marcos Marcolin
> Software Engineer | PHP
> www.marcosmarcolin.com.br
>

Re: [PHP-DEV] New RFC : empty() function

[Marcos Marcolin]

Hi Alessandro,

It would be better to add syntax highlighting to the code examples of 
your RFC, it is not legal to read/understand the texts as if they were 
just texts.


---
Marcos Marcolin
Software Engineer | PHP
www.marcosmarcolin.com.br

Re: [PHP-DEV] New RFC : empty() function

[Alessandro Rosa]

Hi Mr. Tommins,

thank you very much for all your very valuable advices.
You can read a more robust discussion about my RFC at

https://wiki.php.net/rfc/empty_function

Regards,

Alessandro Rosa

Il giorno lun 30 ott 2023 alle ore 23:54 Rowan Tommins <
rowan.coll...@gmail.com> ha scritto:

> On 30/10/2023 12:24, Alessandro Rosa wrote:
> > I have posted a new RFC at this link
> > https://wiki.php.net/rfc/empty_function where I suggested some
> > improvements to the standard built-in empty() function and provided a
> > number of examples.
>
>
> Hi, and welcome!
>
>
> First, regarding the clarity of the proposal.
>
> You have a few pieces of sample code in the RFC, but the "expected
> value" comments don't actually match what that code would output. Rather
> than inline comments on each line, I suggest you give the current output
> of the whole code, followed by the expected / desired output. I would
> also suggest replacing "" with "\n", to keep the code smaller.
>
> Similarly, your PHP-implemented version of the function is trying to be
> far too clever. If you want to illustrate what you think the rules
> should be, you need a clear, well-commented function implementing those
> rules. The first if statement, for instance, is just a very confusing
> way to write "if ( $input === null ) { return true; }"
>
> Neither style of example really explains why you think your proposed
> rules make sense. *Why* should boolean true be considered empty? In what
> situation would you call the function with no arguments and expect a
> meaningful response?
>
>
> Second, regarding timescales.
>
> As documented at https://wiki.php.net/rfc/releaseprocess the official
> policy of the project is that backwards compatibility can only be broken
> in a major version - that is, the next chance to break compatibility is
> in 9.0, not 8.anything. While there are often grey areas around this
> rule, there is absolutely no question that empty() could be removed any
> time before that. If anything, proposing removal in 10.0 might be more
> reasonable.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] New RFC : empty() function

[Rowan Tommins]

On 30/10/2023 12:24, Alessandro Rosa wrote:
I have posted a new RFC at this link 
https://wiki.php.net/rfc/empty_function where I suggested some 
improvements to the standard built-in empty() function and provided a 
number of examples.



Hi, and welcome!


First, regarding the clarity of the proposal.

You have a few pieces of sample code in the RFC, but the "expected 
value" comments don't actually match what that code would output. Rather 
than inline comments on each line, I suggest you give the current output 
of the whole code, followed by the expected / desired output. I would 
also suggest replacing "" with "\n", to keep the code smaller.


Similarly, your PHP-implemented version of the function is trying to be 
far too clever. If you want to illustrate what you think the rules 
should be, you need a clear, well-commented function implementing those 
rules. The first if statement, for instance, is just a very confusing 
way to write "if ( $input === null ) { return true; }"


Neither style of example really explains why you think your proposed 
rules make sense. *Why* should boolean true be considered empty? In what 
situation would you call the function with no arguments and expect a 
meaningful response?



Second, regarding timescales.

As documented at https://wiki.php.net/rfc/releaseprocess the official 
policy of the project is that backwards compatibility can only be broken 
in a major version - that is, the next chance to break compatibility is 
in 9.0, not 8.anything. While there are often grey areas around this 
rule, there is absolutely no question that empty() could be removed any 
time before that. If anything, proposing removal in 10.0 might be more 
reasonable.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New RFC : empty() function

[Kamil Tekiela]

I would be voting against any function that checks for "empty". The
`empty()` construct we have now should almost never be used in any
reasonable code. It should be avoided at all cost. For this reason, I
see no need to introduce a new variant of the same thing. I also don't
believe there is any need to fix or change the existing construct.
Leave it as it is for use in legacy projects. Maybe in a distant
future we will be able to deprecate it or maybe we won't. While I
personally consider it a menace, I don't mind it existing in the
language.

But please do not add any similar functionality.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New RFC : empty() function

[Hamza Ahmad]

Hi there, it's a legacy function, and I don't think we can afford or
we should consider this bc break. Though I don't use this function
myself and also prefer other methods of input validation, still there
are a lot of people that use it. Renaming this to is_empty will bring
a bc break. However, the improvements to this function are worth
considering.
Ahmad

On 10/30/23, Alessandro Rosa  wrote:
> Thanks everybody for joining this discussion.
> I appreciated a lot  the points you raised, as they are helping me to
> update and improve my rfc,
> whose meaning, as I hope, would look clearer than the earlier version.
>
> Improvements must be achieved, whatever they would cost.
> Ambiguities shall be resolved. I think this is the first principle in
> computer science: 0 or 1 ! :-D
> In any case, they are not assumed to be resort into cut-off transitions:
> they may be achieved within 3, 4 or 5 versions.
> Don't be scared.
> I have implemented my version in my own library and it works like a charm:
> you'll have exactly what you read.
>
> Alessandro Rosa
>
> Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife  ha
> scritto:
>
>> >
>> > This is exactly where the problem lies. Is a string with just
>> > whitespace
>> > empty? Why would an ArrayObject with count 0 not be considered to be
>> empty
>> > while an array with count 0 is? "empty" is subjective and therefore not
>> > a
>> > reliable function to use. Especially in legacy code I find that people
>> use
>> > `empty` where they should've been using `count() === 0` and have
>> > resulted
>> > in bugs that weren't discovered until months or years later. The
>> variations
>> > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null`
>> already
>> > check all the scenarios you need, without risking funky bugs due to how
>> the
>> > internal check for "falsy" values works.
>> >
>>
>> trust me, Ive worked on some terrible code bases that do
>> exactly that and have variables redefined or dynamically assigned
>> and you have to really check if it has been assigned a value or
>> not and what value.
>>
>> It might be forgotten by everyone because of how far PHP has come
>> but there is still extensive use of the @ suppressor and the
>> alternative to empty would be
>>
>> if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
>>
>>
>> empty() is 1 of 3 functions i believe that does not throw an undefined
>> variable warning if you don't @ suppress the variable you are passing in.
>>
>> So if you want to get rid of empty, can we reignite the talks to finally
>> get rid of @
>>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New RFC : empty() function

[Alessandro Rosa]

Thanks everybody for joining this discussion.
I appreciated a lot  the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.

Improvements must be achieved, whatever they would cost.
Ambiguities shall be resolved. I think this is the first principle in
computer science: 0 or 1 ! :-D
In any case, they are not assumed to be resort into cut-off transitions:
they may be achieved within 3, 4 or 5 versions.
Don't be scared.
I have implemented my version in my own library and it works like a charm:
you'll have exactly what you read.

Alessandro Rosa

Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife  ha
scritto:

> >
> > This is exactly where the problem lies. Is a string with just whitespace
> > empty? Why would an ArrayObject with count 0 not be considered to be
> empty
> > while an array with count 0 is? "empty" is subjective and therefore not a
> > reliable function to use. Especially in legacy code I find that people
> use
> > `empty` where they should've been using `count() === 0` and have resulted
> > in bugs that weren't discovered until months or years later. The
> variations
> > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null`
> already
> > check all the scenarios you need, without risking funky bugs due to how
> the
> > internal check for "falsy" values works.
> >
>
> trust me, Ive worked on some terrible code bases that do
> exactly that and have variables redefined or dynamically assigned
> and you have to really check if it has been assigned a value or
> not and what value.
>
> It might be forgotten by everyone because of how far PHP has come
> but there is still extensive use of the @ suppressor and the
> alternative to empty would be
>
> if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
>
>
> empty() is 1 of 3 functions i believe that does not throw an undefined
> variable warning if you don't @ suppress the variable you are passing in.
>
> So if you want to get rid of empty, can we reignite the talks to finally
> get rid of @
>

Re: [PHP-DEV] New RFC : empty() function

[tag Knife]

>
> This is exactly where the problem lies. Is a string with just whitespace
> empty? Why would an ArrayObject with count 0 not be considered to be empty
> while an array with count 0 is? "empty" is subjective and therefore not a
> reliable function to use. Especially in legacy code I find that people use
> `empty` where they should've been using `count() === 0` and have resulted
> in bugs that weren't discovered until months or years later. The variations
> of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already
> check all the scenarios you need, without risking funky bugs due to how the
> internal check for "falsy" values works.
>

trust me, Ive worked on some terrible code bases that do
exactly that and have variables redefined or dynamically assigned
and you have to really check if it has been assigned a value or
not and what value.

It might be forgotten by everyone because of how far PHP has come
but there is still extensive use of the @ suppressor and the
alternative to empty would be

if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}


empty() is 1 of 3 functions i believe that does not throw an undefined
variable warning if you don't @ suppress the variable you are passing in.

So if you want to get rid of empty, can we reignite the talks to finally
get rid of @

Re: [PHP-DEV] New RFC : empty() function

[Alessandro Rosa]

Thanks everybody for joining this discussion.
I appreciated a lot  the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.

Alessandro

Il giorno lun 30 ott 2023 alle ore 16:36 Lynn  ha scritto:

> On Mon, Oct 30, 2023 at 4:21 PM tag Knife  wrote:
>
> > >
> > > However, according to my example, the variable is defined and has its
> > > value as 0 or false, and empty() returns true anyway. I confess that
> > > I've had some problems like this, and we chose not to use empty(), as
> > > sometimes 0 or false makes sense as a valid value.
> > >
> >
> > That is exactly as the documentation explains it.
> > empty is to check if a variable is not holding a usable value.
> > 0, false, true are all valid values and show the variable is not
> > empty.
> >
> > The purpose for empty is to check for undefined variables, empty
> > arrays or empty strings.
> > eg. "", [], null or undefined.
> >
>
> This is exactly where the problem lies. Is a string with just whitespace
> empty? Why would an ArrayObject with count 0 not be considered to be empty
> while an array with count 0 is? "empty" is subjective and therefore not a
> reliable function to use. Especially in legacy code I find that people use
> `empty` where they should've been using `count() === 0` and have resulted
> in bugs that weren't discovered until months or years later. The variations
> of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already
> check all the scenarios you need, without risking funky bugs due to how the
> internal check for "falsy" values works.
>

Re: [PHP-DEV] New RFC : empty() function

[Lynn]

On Mon, Oct 30, 2023 at 4:21 PM tag Knife  wrote:

> >
> > However, according to my example, the variable is defined and has its
> > value as 0 or false, and empty() returns true anyway. I confess that
> > I've had some problems like this, and we chose not to use empty(), as
> > sometimes 0 or false makes sense as a valid value.
> >
>
> That is exactly as the documentation explains it.
> empty is to check if a variable is not holding a usable value.
> 0, false, true are all valid values and show the variable is not
> empty.
>
> The purpose for empty is to check for undefined variables, empty
> arrays or empty strings.
> eg. "", [], null or undefined.
>

This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people use
`empty` where they should've been using `count() === 0` and have resulted
in bugs that weren't discovered until months or years later. The variations
of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already
check all the scenarios you need, without risking funky bugs due to how the
internal check for "falsy" values works.

Re: [PHP-DEV] New RFC : empty() function

[tag Knife]

>
> However, according to my example, the variable is defined and has its
> value as 0 or false, and empty() returns true anyway. I confess that
> I've had some problems like this, and we chose not to use empty(), as
> sometimes 0 or false makes sense as a valid value.
>

That is exactly as the documentation explains it.
empty is to check if a variable is not holding a usable value.
0, false, true are all valid values and show the variable is not
empty.

The purpose for empty is to check for undefined variables, empty
arrays or empty strings.
eg. "", [], null or undefined.

Re: [PHP-DEV] New RFC : empty() function

[Lynn]

On Mon, Oct 30, 2023 at 1:24 PM Alessandro Rosa 
wrote:

> Hi,
>
> I have posted a new RFC at this link
> https://wiki.php.net/rfc/empty_function
> where I suggested some improvements to the standard built-in empty()
> function and provided a number of examples.
>
> Thanks,
>
> Alessandro Rosa
> WEB : http://alessandrorosa.altervista.org
> LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/


If anything I'd rather see `empty()` disappear, but I'll settle with a
warning to be cautious when using it. We don't need a replacement as you
should create your own function to validate what you consider "empty" or
not based on the given context and variable type.  For me `(bool) false or
"(int) 0" isn't empty either, it's still a value of sorts.

Re: [PHP-DEV] New RFC : empty() function

[Marcos Marcolin]

Hello,

I understand that the idea of ​​the RFC is about some behaviors of 
empty(), e.g.:


```php $var = ''; var_dump(empty($var)); // true $var= []; 
var_dump(empty($var)); // true $var= 0; var_dump(empty($var)); // true 
var_dump(empty($empty)); // true $var= true; var_dump(empty($var)); // 
false, $varis defined and has value $str = false; var_dump(empty($var)); 
// true, $varis defined and has value ```


According to the manual: “determine whether a variable is empty”.

However, according to my example, the variable is defined and has its 
value as 0 or false, and empty() returns true anyway. I confess that 
I've had some problems like this, and we chose not to use empty(), as 
sometimes 0 or false makes sense as a valid value.


Also, having is_empty() would be nice, but keeping it empty, otherwise 
there would be a huge break.


Maybe think of a strict empty() mode? Even so, it would change behavior.

Sorry if I didn't understand the discussion correctly.

Re: [PHP-DEV] New RFC : empty() function

[Aleksander Machniak]

On 30.10.2023 13:24, Alessandro Rosa wrote:

Hi,

I have posted a new RFC at this link https://wiki.php.net/rfc/empty_function
where I suggested some improvements to the standard built-in empty()
function and provided a number of examples.


Forget about deprecating empty(). No chance I'd vote for that. The RFC 
is not clear either.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New RFC : empty() function

[Kamil Tekiela]

Hi,

I don't understand what you are proposing and what problem you are trying
to fix. The RFC is not explaining things well.

Re: [PHP-DEV] New RFC about variables.

[Rowan Collins]

On Fri, 25 Jan 2019 at 10:32, Глеб Жуков  wrote:

> Hi, my name is Gleb Zhukov.
>
> In my RFC I want to propose to use a new entities(abstractions), like
> *objects*, *structures* and *data* instead of variables. It gives such
> advatege like a mental division of different, independent entities(objects,
> structures, data) in any language.
>

Hi Gleb!

This sounds a lot like how Perl uses "sigils" for different data types -
$scalar, @array, %hash

The problem with this in a complex language like PHP is that you soon run
out of different characters for the different types you might want to
represent. Note that your example already fails in this regard, because it
suggests "#", which is already used for comments.

When designing a language for the first time, it's an interesting thing to
consider, but in an established language like PHP, it would be very
disruptive, and I don't think it brings that much benefit.

You can get almost the same thing in your own code by naming variables
based on their type (so-called "Hungarian notation").

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] New RFC about variables.

[Michał Brzuchalski]

Is this a joke?

pt., 25 sty 2019 o 11:32 Глеб Жуков  napisał(a):

> Hi, my name is Gleb Zhukov.
>
> In my RFC I want to propose to use a new entities(abstractions), like
> *objects*, *structures* and *data* instead of variables. It gives such
> advatege like a mental division of different, independent entities(objects,
> structures, data) in any language. For example
>
> //If earlier we were using variables to store, or access objects, data and
> everything else
>
> $object = new SomeClass();
> $array = ['one','two' => 'three'];
> $data = 'string';
>
> //Now we will use special "*object*" entities to store or access objects
> (wich may be defined with # character)
>
> #object = new SomeClass();
>
> //Special "*structure*" entities for arrays or any other structures (wich
> may be defined with * character)
>
> *stucrture = ['one', 'two', 'key' => 'val', 'another_key' =>
> 'another_val'];
>
> //And special "*data*" entities for all data (strings, integers, floats,
> booleans) (wich may be defined with % character)
>
> %string = 'abcde';
> %integer = 123;
> %floating = 1.23;
> %boolean = true;
>
> The remaining types(callables, resources), I suppose, should continue to
> store in variables. New characters for our new entities will be discussed
> further in RFC.
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] New RFC

[Dan Ackroyd]

> On 2 Aug 2016, at 09:56, Christoph Becker  wrote:
> For the record: there has been the "Array Of" RFC[1], but that has been
> declined.

It was declined because of the implementation, rather than the idea.

A new proposal with a different implementation should be welcomed to be 
considered.

Cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC

[Rowan Collins]

On 02/08/2016 09:56, Christoph Becker wrote:

For the record: there has been the "Array Of" RFC[1], but that has been
declined.

[1] 


If I remember rightly, the biggest problem raised with typed arrays is 
that type constraints in PHP are checked dynamically every time a 
function is called, so the cost of iterating the array to test its type 
can be rather costly:


function foo(Thing[] $things) { }

$data = array_fill(0, 1000, new Thing);
foo($data); // performs 1000 instanceof checks
foo($data); // performs another 1000 instanceof checks
$data[] = new NotAThing;
foo($data); // will throw error only after 1001 instanceof checks
# TOTAL: 3001 instanceof checks


This is not the same with generics, because the container itself 
performs the check, as items are added:


function foo(TypedArray $things) { }

$data = new TypedArray;
foreach ( array_fill(0, 1000, new Thing) as $thing ) {
$data->add($thing); // 1000 instanceof checks here
}
foo($data); // performs one instanceof check on the container
foo($data); // performs one instanceof check on the container
$data->add(new NotAThing); // performs 1 instanceof check and errors
# TOTAL: 1003 instanceof checks

In this trivial example, you could replace the foreach loop with 
something like $data->fill(0, 1000, new Thing) and reduce the whole 
thing to 4 instanceof checks. There is no equivalent shortcut for the 
Thing[] version.



This is a fundamental problem with PHP's type constraints - because they 
are not attached to the value itself, they act as assertions that must 
be executed repeatedly. The more complex we make them, and the more 
places they're added, the more this becomes a limiting factor.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: [PHP-DEV] New RFC

[Tomáš Holan]

Oh that's sad, cause it's missing feature. But what we can do. Thanks for info 
Christoph.

- Původní zpráva - 
Odesilatel: "Christoph Becker" <cmbecke...@gmx.de> 
Příjemce: "Dan Ackroyd" <dan...@basereality.com>, "Tomáš Holan" 
<m...@tomasholan.eu> 
Kopie: internals@lists.php.net 
Datum: 02.08.2016 10:56 
Předmět: Re: [PHP-DEV] New RFC 

On 02.08.2016 at 09:11, Dan Ackroyd wrote:

> It has been thought about, and several people are looking at an
> implementation of generics: https://wiki.php.net/rfc/generics However,
> it seems quite hard to implement.
> 
> I am beginning to wonder if rather than aiming for full support of
> generics listed in that RFC, instead we just aimed for arrays that can
> only contain one type of variable as a good first step.

For the record: there has been the "Array Of" RFC[1], but that has been
declined.

[1] <https://wiki.php.net/rfc/arrayof>

-- 
Christoph M. Becker




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC

[Christoph Becker]

On 02.08.2016 at 09:11, Dan Ackroyd wrote:

> It has been thought about, and several people are looking at an
> implementation of generics: https://wiki.php.net/rfc/generics However,
> it seems quite hard to implement.
> 
> I am beginning to wonder if rather than aiming for full support of
> generics listed in that RFC, instead we just aimed for arrays that can
> only contain one type of variable as a good first step.

For the record: there has been the "Array Of" RFC[1], but that has been
declined.

[1] 

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC

[Peter Lind]

On 2 August 2016 at 09:11, Dan Ackroyd  wrote:

> Hi Tomáš,
>
> It has been thought about, and several people are looking at an
> implementation of generics: https://wiki.php.net/rfc/generics However,
> it seems quite hard to implement.
>
> I am beginning to wonder if rather than aiming for full support of
> generics listed in that RFC, instead we just aimed for arrays that can
> only contain one type of variable as a good first step.
>
> cheers
> Dan
>
>
It's probably worth noting that creating "arrays" that can only contain one
type of variable is already possible by implementing ArrayAccess, Iterator
and Countable.

It won't work exactly like arrays and probably never will (see
https://www.mail-archive.com/internals%40lists.php.net/msg59199.html) but
might be worth as a starting point.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] New RFC

[Dan Ackroyd]

Hi Tomáš,

It has been thought about, and several people are looking at an
implementation of generics: https://wiki.php.net/rfc/generics However,
it seems quite hard to implement.

I am beginning to wonder if rather than aiming for full support of
generics listed in that RFC, instead we just aimed for arrays that can
only contain one type of variable as a good first step.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Ott]

Am 14.04.2015 um 00:16 schrieb Levi Morrison:
 - IMO, the method should be called when the class is created, just after 
 every parent class and implemented interfaces are created.
 
 In general I think static class data and static class constructors are
 a sign of poorly designed code, which means I am against this feature.

Thanks for the flowers as we would say in Germany! I didn't hear I'm
doing poor code for a long time now :(

-- 
DerOetzi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Ott]

Am 14.04.2015 um 16:33 schrieb Dan Ackroyd:

 Here is some feedback then:
 
 From the RFC:
 - Trigger for “magic” method call: First call to class, either first call to 
 __construct(...) or first call to any public or protected static method or 
 property of the class
 
 I don't think this doesn't cover all cases that it needs to. For
 example calling unserialze on some data that results in a class that
 has this static initializer should mean that it would be invoked?
 Similarly ReflectionClass::newInstanceWithoutConstructor also creates
 a class in a way that isn't covered in the RFC, but presumably should
 be.
 

Your correct I forgot this two scenarios of first calls to a class.
Thanks for the hint!

But in the new draft (v0.4) I'm preparing at the moment I'll try to
formulate the trigger first call more common by comparing it to the
same trigger for __autoload function. Then these two scenarios should be
included as well.

 From the RFC.
 the static class constructor should be able to throw a catchable Exception
 for user error handling, if it is not possible to initialize. The open issue 
 for
 me is, what the behavior on recalling the static class constructor afterward 
 is.
 There are two possible behaviors I do not know which one I really would 
 prefer so far.
 
 You missed the third and in my opinion correct one; the static
 initializer would only ever be called once. 

I think this is suggested behaviour 1, isn't it?

On recall of the static class constructor a fatal error is raised to
ensure it is only called once...

If the programmer catches
 the exception and forces the program to continue, that is their own
 problem. Adding complexity to a language to try to work around
 programmers ignoring exceptions is not a good idea.
 

I agree to this point that ignoring an exception is a bad idea. I think
the example-code is a bit confusing, because the empty catch-block gives
the impression that the exception is ignored. But what is really meant
by behaviour 2 is that the programmer has the opportunity to handle the
exception not by exiting his programm, but by cleaning up the
situation and afterwards retry the code which failed before.

I will try to clearify this in one of the next draft versions.


 I think the RFC needs to be clearer in the specification of the order
 that static initialization is called in. e.g. class B extends class A.
 Both A and B have static initialization blocks. When a user calls `new
 B()` which static initialization block is called first?
 

While rewriting the draft for v0.4 I although noticed this gap inside
specification and came to the conclusion that this is the third first
call scenario I haved missed. Because inheritance by using keyword
extends is already a first call to class A.

 cheers
 Dan
 

Thanks for really constructive feedback, that one really helps me for
the next draft of rfc

Regards

-- 
DerOetzi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Dan Ackroyd]

Hi Johannes,

On 13 April 2015 at 13:37, Johannes Ott m...@deroetzi.de wrote:
 Hi,

 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.



Here is some feedback then:

From the RFC:
 - Trigger for “magic” method call: First call to class, either first call to 
 __construct(...) or first call to any public or protected static method or 
 property of the class

I don't think this doesn't cover all cases that it needs to. For
example calling unserialze on some data that results in a class that
has this static initializer should mean that it would be invoked?
Similarly ReflectionClass::newInstanceWithoutConstructor also creates
a class in a way that isn't covered in the RFC, but presumably should
be.

From the RFC.
 the static class constructor should be able to throw a catchable Exception
 for user error handling, if it is not possible to initialize. The open issue 
 for
 me is, what the behavior on recalling the static class constructor afterward 
 is.
 There are two possible behaviors I do not know which one I really would 
 prefer so far.

You missed the third and in my opinion correct one; the static
initializer would only ever be called once. If the programmer catches
the exception and forces the program to continue, that is their own
problem. Adding complexity to a language to try to work around
programmers ignoring exceptions is not a good idea.

I think the RFC needs to be clearer in the specification of the order
that static initialization is called in. e.g. class B extends class A.
Both A and B have static initialization blocks. When a user calls `new
B()` which static initialization block is called first?

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Jakub Kubíček]

I would rather appreciate run-time class properties initialization.


Best regards,
  Kubo2

2015-04-13 15:37 GMT+02:00 Johannes Ott m...@deroetzi.de:

 Hi,

 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

 As I already mentioned in the prediscussion thread here:

 For being my first change to the PHP core, I would be very happy, if
 someone of the old stager would help me with the implementation of
 this RFC if it is accepted.

 Regards

 --
 DerOetzi

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Dan Ackroyd]

On 14 April 2015 at 17:39, Johannes Ott m...@deroetzi.de wrote:
 Am 14.04.2015 um 16:33 schrieb Dan Ackroyd:

 Here is some feedback then:


Johannes Ott wrote:
 But in the new draft (v0.4) I'm preparing at the moment I'll try to
 formulate the trigger first call more common by comparing it to the
 same trigger for __autoload function.

Hmm. The language will need to be quite clear then - sometimes classes
are autoloaded when they aren't instantiated. e.g. for just normal
reflection of classes, the class is autoloaded if it isn't already
present, or some people may autoload all the things ahead of time, to
avoid any delay when responding to a request.

Johannes Ott wrote:
Danack wrote:
 You missed the third and in my opinion correct one; the static
 initializer would only ever be called once.
 I think this is suggested behaviour 1, isn't it?

I read that section very differntly.

On recall of the static class constructor a fatal error is raised to
ensure it is only called once and initialized before exception was
thrown properties will not be reinitialized.

I read that as it implies that it would be possible to call the static
initializer again, and in that case a fatal error would be thrown. If
the initializer is only ever called once, it would be clearer to say
that as a 'positive' statement, as opposed to saying a 'negative' of
what wouldn't be allowed - i.e. single statements are clearer than any
kind of double-negative statements.

Johannes Ott wrote:
Danack wrote:
 I think the RFC needs to be clearer in the specification of the order
 that static initialization is called in.
 Because inheritance by using keyword
 extends is already a first call to class A.

tbh, it's quite likely that looking at Java or some other language
that has static initializers and copying that behaviour for precedence
could be the best choice.

However the behaviour might not be mappable directly, due to
differences in PHP's inheritance and class model, in particular the
late static binding.

class A {
static function __staticInit() {
static::foo();
}

static function foo() {
echo This is A::foo\n;
}
}

class B extends A {
static function foo() {
echo This is B::foo\n;
}
}

B::__staticInit(); //Output is 'This is B::foo'

It's pretty easy to imagine some cases where there are circular
dependenciesso the RFC would need to be precise about exactly what
the rules are.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Schlüter]

On Tue, 2015-04-14 at 11:49 +0200, Johannes Ott wrote:
 Am 14.04.2015 um 00:16 schrieb Levi Morrison:
  - IMO, the method should be called when the class is created, just after 
  every parent class and implemented interfaces are created.
  
  In general I think static class data and static class constructors are
  a sign of poorly designed code, which means I am against this feature.
 
 Thanks for the flowers as we would say in Germany! I didn't hear I'm
 doing poor code for a long time now :(

If static elements need initialisation they apparently have state. If
they have state they in 95% of the cases shouldn't be static but bound
to an object instance. Yes there might be cases where this is a good
design, but the language should provide the syntax sugar to lead the 95%
to write good code instead of leading them to write bad code which can
be tested harder and where changes might have unexpected side-effects.

So even if you're code is good and your own use-case is good design,
which I won't question, I don't think advertising it to all users by
providing a language feature is good.

johannes



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Ott]

Am 13.04.2015 um 18:54 schrieb Johannes Schlüter:
 On Mon, 2015-04-13 at 17:23 +0200, Johannes Schlüter wrote:
 Why am I saying it makes the language more complex? - Your proposal
 seems to miss mentioning when exactly the method is executed. what is
 
 Ah, I missed this
 
 Trigger for “magic” method call: First call to class, either
 first call to __construct(...) or first call to any public or
 protected static method or property of the class 
 
 Which means adding a flag, which has to be checked on every method call
 or other access to *any* class and leads to completely random (from
 perspective of average user) behavior while this feature can't be used
 for an obvious task like registering itself as plugin into some
 registry.
 
 -1
 
 johannes
 

The obvious task is to initial the state of the class before usage as I
wrote inside my introduction of the RFC.

I think there is no random behavior (not more then other so called
magic methods). But I see that I forgot this point in the discussion
part because we already had this point on the prediscussion. Will add
this tomorrow, with my exact answer to this point,

Thanks for reminder.

https://wiki.php.net/rfc/static_class_constructor

-- 
DerOetzi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[S.A.N]

 Okay I will think about the alternative names, I somehow like
 __classInit you proposed or __classConstruct

I like simple: __init()

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Levi Morrison]

On Mon, Apr 13, 2015 at 7:37 AM, Johannes Ott m...@deroetzi.de wrote:
 Hi,

 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

The static constructor cannot be called by the user, which means it
shouldn't even register as a function. Additionally, it is always
private. Given these constraints I would prefer to change this syntax:

class Config {

private static $arIni;

private static function __static() {
$self::$arIni = parse_ini_file('config.ini');
}
}

To this (borrowed from Java):

class Config {

private static $arIni;

static {
$self::$arIni = parse_ini_file('config.ini');
}
}

I do not see any reason to do the former unless the latter has
conflicts in the parser, which I don't think it would.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Levi Morrison]

 - IMO, the method should be called when the class is created, just after 
 every parent class and implemented interfaces are created.

In general I think static class data and static class constructors are
a sign of poorly designed code, which means I am against this feature.
If it does make it though I agree with this statement above. The
behavior proposed in the RFC makes it non-obvious when the class
constructor is run and would much prefer it happening immediately
after definition.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Schlüter]

On Mon, 2015-04-13 at 21:14 +0200, Johannes Ott wrote:
 The obvious task is to initial the state of the class before usage as I
 wrote inside my introduction of the RFC.

That is one possible task users are going to try doing. Users are more
creative.

 I think there is no random behavior (not more then other so called
 magic methods). But I see that I forgot this point in the discussion
 part because we already had this point on the prediscussion. Will add
 this tomorrow, with my exact answer to this point,

It is random in the sense that a seemingly unrelated change somewhere
in an application changes order in other places, too.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] New RFC draft static class constructor

[Marcio Almada]

Hi,

2015-04-13 10:37 GMT-03:00 Johannes Ott m...@deroetzi.de:
 Hi,

 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

 As I already mentioned in the prediscussion thread here:

 For being my first change to the PHP core, I would be very happy, if
 someone of the old stager would help me with the implementation of
 this RFC if it is accepted.

 Regards

 --
 DerOetzi

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


I know this is still a draft, but conceptually I don't like this
feature. I always avoid static
state on classes as much as possible and I think this should be
avoided. But this is my
personal opinion. Some suggestions:

In case the RFC passes, I'd prefer to have a `static{ ... }` block
instead of yet
another static __ method. The reason is that this kind of construct is
already known
on other languages as `static{...}` and that feels more organized IMMO.

In case you decide to proceed with the magic method approach, I'd
prefer the more
verbose `__staticConstruct` name because it seems clearer.

Thanks,
Márcio

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Ott]

Am 13.04.2015 um 17:29 schrieb Benjamin Eberlei:
 What would happen if you call the parent constructor:
 
 class A extends B {
static public function __static() {
 B::__static();
}
 }
 

Please have a closer look to the definition of the function:

https://wiki.php.net/rfc/static_class_constructor#proposal

it should be declared private to prohibit any access from outside the
of the class itself.

Although see the the answer 2 in discussion section:

https://wiki.php.net/rfc/static_class_constructor#inheritance_of_the_class_constructor

Thanks for feedback

 On Mon, Apr 13, 2015 at 5:23 PM, Johannes Schlüter johan...@schlueters.de
 wrote:
 
 Hi,

 On Mon, 2015-04-13 at 15:37 +0200, Johannes Ott wrote:
 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

 In my opinion this makes the language way more complex as there are more
 places which suddenly execute code but solves a small problem compared
 to that. (Which actually is an issue many people would suggest to avoid
 completely instead of ennobling this with a language feature.

 Why am I saying it makes the language more complex? - Your proposal
 seems to miss mentioning when exactly the method is executed. what is
 the output of


 a.php:
 ?php
 echo 'A: '.__FILE__.':'.__LINE__.\n;
 class A {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }
 echo 'B: '.__FILE__.':'.__LINE__.\n;
 class B {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }
 echo 'C: '.__FILE__.':'.__LINE__.\n;
 ?

 b.php:
 ?php
 echo 'D: '.__FILE__.':'.__LINE__.\n;

 C::$foo = 23;
 echo 'E: '.__FILE__.':'.__LINE__.\n;

 include 'a.php';
 echo 'F: '.__FILE__.':'.__LINE__.\n;


 class C {
 static $foo = 0;
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }

 echo 'G: '.__FILE__.':'.__LINE__.\n;

 class D extends B {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }

 echo 'H: '.__FILE__.':'.__LINE__.\n;
 ?


 Mind that in b.php we make use of class C above the declaration, which
 we can do as C is a simple class and can be bound early during
 compilation. Class D however can only be bound during run-time, after
 including a.php, which happens after C was already used.

 johannes


 

-- 
DerOetzi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Ott]

Am 13.04.2015 um 18:02 schrieb François Laupretre:
 De : Johannes Ott [mailto:m...@deroetzi.de]
 finally I managed to do my first RFC draft.

 https://wiki.php.net/rfc/static_class_constructor

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.
 
 Interesting. It also allows to respect PSR-1, which says 'Files SHOULD either 
 declare symbols (classes, functions, constants, etc.) or cause side-effects 
 (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both' 
 (see 
 https://github.com/flaupretre/automap/blob/develop/src/classes/Automap.php 
 for an example).
 
 Comments :
 
 - __static is ambiguous and does not reflect the method's role. Even if 
 longer, I definitely prefer __staticInit or, even better, __classInit.
 

Okay I will think about the alternative names, I somehow like
__classInit you proposed or __classConstruct

 - IMO, the method should be called when the class is created, just after 
 every parent class and implemented interfaces are created. If some load a 
 bunch of classes they don't use, that's their problem, not ours. It is not a 
 reason to follow a two-step process. A properly written program uses 
 autoloading and loads the classes it needs only. Another argument is that I'm 
 not sure it is possible to catch every case of read access to static 
 properties.

On the one hand I think we should respect most of the user-land code as
far as possible and on the other hand I think there should be the
possibility to handle the being initialized or not initialized inside
the class action.

 
 - I think you should provide a destructor method because there can be a need 
 to cleanup/close the resources opened when initializing the class. It can be 
 open files, sockets, or any other resource, but, IMO, they need to be 
 explicitly closed when the request ends.
 

Please see my answer 4 in discussion section for this:

https://wiki.php.net/rfc/static_class_constructor#need_of_a_class_destructor_to_handle_unload_order_dependencies

 Regards
 
 François
 
 

-- 
DerOetzi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Schlüter]

On Mon, 2015-04-13 at 17:23 +0200, Johannes Schlüter wrote:
 Why am I saying it makes the language more complex? - Your proposal
 seems to miss mentioning when exactly the method is executed. what is

Ah, I missed this

Trigger for “magic” method call: First call to class, either
first call to __construct(...) or first call to any public or
protected static method or property of the class 

Which means adding a flag, which has to be checked on every method call
or other access to *any* class and leads to completely random (from
perspective of average user) behavior while this feature can't be used
for an obvious task like registering itself as plugin into some
registry.

-1

johannes



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] New RFC draft static class constructor

[Johannes Schlüter]

Hi,

On Mon, 2015-04-13 at 15:37 +0200, Johannes Ott wrote:
 finally I managed to do my first RFC draft.
 
 https://wiki.php.net/rfc/static_class_constructor
 
 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

In my opinion this makes the language way more complex as there are more
places which suddenly execute code but solves a small problem compared
to that. (Which actually is an issue many people would suggest to avoid
completely instead of ennobling this with a language feature.

Why am I saying it makes the language more complex? - Your proposal
seems to miss mentioning when exactly the method is executed. what is
the output of


a.php:
?php
echo 'A: '.__FILE__.':'.__LINE__.\n;
class A {
static function __static() {
  echo __CLASS__.'::'.__METHOD__.\n;
}
}
echo 'B: '.__FILE__.':'.__LINE__.\n;
class B {
static function __static() {
  echo __CLASS__.'::'.__METHOD__.\n;
}
}
echo 'C: '.__FILE__.':'.__LINE__.\n;
?

b.php:
?php
echo 'D: '.__FILE__.':'.__LINE__.\n;

C::$foo = 23;
echo 'E: '.__FILE__.':'.__LINE__.\n;

include 'a.php';
echo 'F: '.__FILE__.':'.__LINE__.\n;


class C {
static $foo = 0;
static function __static() {
  echo __CLASS__.'::'.__METHOD__.\n;
}
}

echo 'G: '.__FILE__.':'.__LINE__.\n;

class D extends B {
static function __static() {
  echo __CLASS__.'::'.__METHOD__.\n;
}
}

echo 'H: '.__FILE__.':'.__LINE__.\n;
?


Mind that in b.php we make use of class C above the declaration, which
we can do as C is a simple class and can be bound early during
compilation. Class D however can only be bound during run-time, after
including a.php, which happens after C was already used.

johannes



signature.asc
Description: This is a digitally signed message part

RE: [PHP-DEV] New RFC draft static class constructor

[François Laupretre]

 De : Johannes Ott [mailto:m...@deroetzi.de]
 finally I managed to do my first RFC draft.
 
 https://wiki.php.net/rfc/static_class_constructor
 
 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

Interesting. It also allows to respect PSR-1, which says 'Files SHOULD either 
declare symbols (classes, functions, constants, etc.) or cause side-effects 
(e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both' (see 
https://github.com/flaupretre/automap/blob/develop/src/classes/Automap.php for 
an example).

Comments :

- __static is ambiguous and does not reflect the method's role. Even if longer, 
I definitely prefer __staticInit or, even better, __classInit.

- IMO, the method should be called when the class is created, just after every 
parent class and implemented interfaces are created. If some load a bunch of 
classes they don't use, that's their problem, not ours. It is not a reason to 
follow a two-step process. A properly written program uses autoloading and 
loads the classes it needs only. Another argument is that I'm not sure it is 
possible to catch every case of read access to static properties.

- I think you should provide a destructor method because there can be a need to 
cleanup/close the resources opened when initializing the class. It can be open 
files, sockets, or any other resource, but, IMO, they need to be explicitly 
closed when the request ends.

Regards

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New RFC draft static class constructor

[Benjamin Eberlei]

What would happen if you call the parent constructor:

class A extends B {
   static public function __static() {
B::__static();
   }
}

On Mon, Apr 13, 2015 at 5:23 PM, Johannes Schlüter johan...@schlueters.de
wrote:

 Hi,

 On Mon, 2015-04-13 at 15:37 +0200, Johannes Ott wrote:
  finally I managed to do my first RFC draft.
 
  https://wiki.php.net/rfc/static_class_constructor
 
  I hope I have done everything correct so far and I'm looking forward to
  your feedback on it.

 In my opinion this makes the language way more complex as there are more
 places which suddenly execute code but solves a small problem compared
 to that. (Which actually is an issue many people would suggest to avoid
 completely instead of ennobling this with a language feature.

 Why am I saying it makes the language more complex? - Your proposal
 seems to miss mentioning when exactly the method is executed. what is
 the output of


 a.php:
 ?php
 echo 'A: '.__FILE__.':'.__LINE__.\n;
 class A {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }
 echo 'B: '.__FILE__.':'.__LINE__.\n;
 class B {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }
 echo 'C: '.__FILE__.':'.__LINE__.\n;
 ?

 b.php:
 ?php
 echo 'D: '.__FILE__.':'.__LINE__.\n;

 C::$foo = 23;
 echo 'E: '.__FILE__.':'.__LINE__.\n;

 include 'a.php';
 echo 'F: '.__FILE__.':'.__LINE__.\n;


 class C {
 static $foo = 0;
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }

 echo 'G: '.__FILE__.':'.__LINE__.\n;

 class D extends B {
 static function __static() {
   echo __CLASS__.'::'.__METHOD__.\n;
 }
 }

 echo 'H: '.__FILE__.':'.__LINE__.\n;
 ?


 Mind that in b.php we make use of class C above the declaration, which
 we can do as C is a simple class and can be bound early during
 compilation. Class D however can only be bound during run-time, after
 including a.php, which happens after C was already used.

 johannes