Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

[Johannes Ott]

Am 11.03.2015 um 17:21 schrieb Rowan Collins:

 
 My reasoning is that code that is ambiguous is hard to read. If $foo
 can mean either a local variable called $foo or a property of the
 current object called $foo, then you have to know which it is in order
 to understand what code is doing.

So for clean code rules you should do smaller methods if you can't even
see clearly whether you declared $foo locally or not.

 
 This is not about a strict OOP-world, incidentally, it's about scoping
 rules. Java imports object properties into the scope of each method, PHP
 does not. Even if properties had to be declared (which is probably a
 good idea), local variables still wouldn't be - in Java, the fact that
 it's not declared locally means it *must* be coming from somewhere else.


No if it is not declared locally it doesn't mean it's coming from
somewhere else, but it means it is coming from one of the next higher
scopes which is normally the Object.

 I also know that when I was first learning Java at school, it confused
 me immensely which variables I was allowed to access in static contexts.
 In PHP, that's simple - if you can't access $this, you can't access any
 of it's properties.
 

I'm not talking about beginners code, but about professional clean code.
If you're doing as a beginner you can still use the $this keyword to
make it clearer code for you to understand. But if you want to do huge
applications you should have understand the difference between static
and non-static context. And if it would be defined well in PHP, modern
IDEs should be able to help you to do no mistakes.

 
 This is true of any object variable.
 
 These resolve the scope of the property/method to the variable $foo:
 
 $a = $foo-a;
 $foo-some_function(...);
 
 These resolve the scope of the property/method to the variable $this:
 
 $a = $this-a;
 $this-some_function(...);
 

Okay I agree with this point.

 If you want to resolve the scope of a method to the current object
 without using the variable $this, you can also use the static keyword;
 these are equivalent:
 
 $this-some_function(...);
 static::some_function(...);
 // http://3v4l.org/E0XYs

I don't care whether I use $this- or static:: as keyword. In this case
I would even prefer $this- because static in instance context is in my
opinion really confusing.

 
 There is nothing unvariable-like about $this, so if variables begin with
 $, $this should begin with $.
 
 Regards,

Regards

-- 
DerOetzi

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

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

[Marcio Almada]

2015-03-10 12:31 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:

 Hello,

 Le lun. 2 mars 2015 à 00:03, Marcio Almada marcio.w...@gmail.com a
 écrit :


  I'm globally +0.5, however I have some concerns:

 What about constructors?

 Children classes may have a bigger number of arguments for their ctors
 than their parents. Even if not very elegant, it is possible some are
 passing a fixed number of arguments while constructing an object, whether
 that object will take it into account or not.

 Something like:

 class A {
 function __construct($a)
 }

 class B extends A {
 function __construct($a, $b)
 }

 $kind = $bool ? A : B;

 $object = new $kind($foo, $bar);


I think this is somehow covered here
https://wiki.php.net/rfc/strict_argcount#hassle_factor, the example is not
explicit to ctors but the same principles seem to apply. Not sure you have
a deeper point on it though as PHP is a weirdo and allows constructors on
interfaces.

Also, FYI, before we reach discussion phase, there was an idea to ignore
ctors and other magic methods but you are the first person to bring it up
on the ML. I'm not very inclined to ignore any other magic methods other
than *__call* and *__callStatic* for now.



 Why aren't you using E_NOTICE?


 [1]: Run-time notices. Indicate that the script encountered something that
 could indicate an error, but could also happen in the normal course of
 running a script.


I have nothing against E_NOTICE in this case and indeed E_NOTICE seems like
a good fit. I'll add it as an option.


 E_DEPRECATED:
 -1, what is E_DEPRECATED is supposed to be removed in a future version.
 And that is a huge BC break if it happens. Btw, you're not mentioning in
 which version of PHP the support of extra parameters would be removed.


I was sympathetic towards E_DEPRECATED in the early stage of discussion
phase but I'm not anymore. If somebody would like to E_DEPRECATE something
related to argument count in the future, the this person will have to
create another RFC and start the deprecation on PHP 7.1. I'm removing this
option now :)


 E_WARNING:
 -1, IMHO, calling functions/methods with more arguments generally has less
 impact than other aspects that currently generate E_NOTICES (e.g. using
 undefined variables, constants,...). Using an error reporting level
 stronger than for those cases looks inconsistent.


I disagree with the looks inconsistent part. The E_WARNING option would
actually be the most consistent with current PHP behavior. Ex:

function fn($a, $b){}
fn(1);
PHP warning:  Missing argument 2 for fn(), called in...

If we choose E_WARNING both minimum and maximum argument count will have
the same error level. BTW, in some cases an exceeding argument can be even
more dangerous than a missing argument.

I have no strong feelings regarding to the error level, the E_WARNING vs
E_NOTICE seems legit so I'm waiting for more opinions.

Cheers and thanks for the impressive work so far!

 Patrick

 [1] http://php.net/manual/en/errorfunc.constants.php


You're welcome. Thanks for the useful feedback. Hope we can reach a
consensus on the options before the voting starts.

Márcio.

Re: [PHP-DEV] static constructor

[Alexey Zakhlestin]

 On 12 Mar 2015, at 02:21, Johannes Ott m...@deroetzi.de wrote:
 
 So now I want to do my first own proposal for a new function in PHP and
 I hope doing it right with starting a discussion here first.
 
 The purpose of this suggestion is to introduce a static constructor,
 which is called before the first call to class either static or
 non-static to initialize some static properties which are needed by the
 class.
 
 I think about two different possible syntax to realize that purpose:
 
 Version 1 (similar to Java):
 
 class A {
private static $var;
 
static {
 //Do some code here to initialize self::$var;
}
 
 }
 
 Version 2 (a new magic method):
 
 class B {
private static $var;
 
private static function __static() {
//Do some code here to initialize self::$var;
}
 }
 
 My prefered code would be version 2 at the moment.
 
 Looking forward to your feedback,

What about inheritance?
I think dynamic class-constructor would make much more sense.
A function which can analyse real class and do initialisation.

class A
{
protected static function __class_construct()
{
echo get_called_class().” class is defined\n;
}
}

class B extends A
{
}

 output 
A class is defined
B class is defined

-- 
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





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

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

[Johannes Ott]

Am 11.03.2015 um 14:03 schrieb Rowan Collins:
 Johannes Ott wrote on 10/03/2015 20:46:
 okay indeed the dynamic properties are a problem I didn't think about on
 my suggestion. Without the wish to hijack this thread for another
 typesafety discussion, I must say again that PHP needs a less dynamic
 and more declaratively properties concept in my opinion.
 
 Yes, I think a standard way to say that a particular object has strictly
 declared all its properties, and should not allow  would be useful.
 
 (Even with that, though, I'd be against guessing that $foo meant
 $this-foo; it just makes code harder to read.)
 

I disagree, programming Java beside PHP since about 15 years now,
personally I think always having this-keyword, where it is not
necassary in a strict OOP-world, makes the code more unreadable for the
simple fact it is more to read.

 So I would suggest for now to keep the $this variable, but to make it
 more similar to other OOP-languages I would suggest to remove the
 $-character in front. In my opinion it would fit better to other object
 keywords like parent and self as well.
 
 Other OOP languages only don't have a sigil such as $ in front of this
 if they don't have one in front of *any* variable. Why should $this,
 which acts like a normal variable in pretty much every way, drop the $
 when every other variable in the language has one?
 
 Note that the syntax of parent and self is different, and is consistent
 with static member/method access, or more strictly scope resolution.
 You can't pass parent or self around as variables, only use them to
 resolve scopes, so they don't have a $.
 

I only agree a bit, because the keyword this, is what to call a
hybridization, more often used to define the scope of the property or
method you want to use, then used really as a pure variable.

For example:

this-a;
or
this-some_function(...);

just defining the scope as in the current instance is much more used then.

some_function($this);



 That's what sigils are for - making similar things look similar and
 distinct things look distinct.
 
 Regards,

-- 
DerOetzi

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

Re: [PHP-DEV] static constructor

[Patrick Schaaf]

On Thursday 12 March 2015 00:10:15 Rowan Collins wrote:
 On 11/03/2015 23:21, Johannes Ott wrote:

  The purpose of this suggestion is to introduce a static constructor,
  which is called before the first call to class either static or
  non-static to initialize some static properties which are needed by the
  class.
 
 Can you give an example use case for when this would be useful? I'm
 struggling to think of one for which there isn't already an established
 coding pattern...

It's useful everywhere you now have more than one method starting

if (!static::$is_initialized) static::initialize_me();

Some examples from our codebase:

- a session wrapper class, hiding $_SESSION behind setter/getter methods, 
where the static class initialization determines which cookie to use, 
depending on some global feature flags, and which session backend to use, 
depending on current availability. (main purpose, apart from clean calling 
side code just using the setters/getters, is to get the lazy_write 
functionality Yasuo tried to introduce recently)

- computation of some class properties from others, like doing an array_flip 
on one to get a reverse mapping.

- definition of computed constants, in various places. Partly obsolete now 
that class constants support constant expressions, but needed as soon as these 
are not really constant.

- setting up some class properties used by various methods, that should depend 
on some global feature flags (defined by the users of the class, usually 
toplevel scripts)

- invariant checks on subclasses, in various places, where concrete subclasses 
set up some static properties of a configuration nature, and I want to make 
sure in the base class, as early as possible, that the values are consistent 
and make sense, avoiding checks spread all over the place in various methods.

Of course, most of this could be done by code outside the class definition, in 
the same file. But that has proven, in the past, a fountain of joy wrt. 
placement, with variations needed for APC and opcache, and general frustration 
all around.

best regards
  Patrick







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

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Zeev Suraski]

 -Original Message-
 From: Ole Markus With [mailto:olemar...@olemarkus.org]
 Sent: Thursday, March 12, 2015 10:10 AM
 To: Pierre Joye; Zeev Suraski
 Cc: PHP internals
 Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints



 On 03/11/2015 09:05 PM, Pierre Joye wrote:
  On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote:
 
  The vote on the Coercive Scalar Type Hints is now open for voting.
 
 
 
  The latest version of the RFC includes changes discussed on
  internals@
  last
  week:
 
  1.  Accept string-bool and int-bool conversions (false-bool is not
  supported)
 
  2.  Accept leading/trailing spaces in string-number conversions.
 
 
 
  wiki.php.net/rfc/coercive_sth
 
  wiki.php.net/rfc/coercive_sth#vote
 
  Voted no for the following reasons:
 
  - change default casting, which has been working since years,
  consistently inconsistent
  - due to the previous nature of changes, we have no way to be sure we
  won't break anything badly out there
  - big changes in the RFC+patch between last discussions and vote.
  Should not be allowed, can't veto it so voted no
 

 I changed my vote to no for the same reasons.

I'm sorry to hear that Ole Markus.  I do want to address these concerns:

 - change default casting, which has been working since years,
 consistently inconsistent
 - due to the previous nature of changes, we have no way to be sure we
 won't break anything badly out there

Casting rules aren't touched - it's rules for internal function arguments
that are changed.  This has been a key premise of this proposal since the
beginning;  Contrary to the 2nd statement, we have a pretty good way of
knowing it won't break things badly out there - running it with real world
apps and our test suite.  As the Impact On Real World Applications section
suggests (wiki.php.net/rfc/coercive_sth#changes_to_internal_functions) -
the real world impact is minimal, since the conversion which are blocked are
rarely relied upon in apps.  The issues you do get are almost always
legitimate issues - with excellent signal to noise ratio.  Users would have
several YEARS to fix these issues before they become errors and not
warnings.  Many of the compatibility breakages we've done over the years
(and in 7) had / would have a lot farther reaching impact - often with zero
end-user gain to show for it.
What is being consistently ignored by everyone is the fact that large
projects - with the absence of having a good dynamic option - are likely to
implement strict project-wide, resulting in WAAAY bigger breakage, since the
strict mode does not differentiate between sensible conversions, that have
been relied upon in PHP for the last 20 years (32 - 32) and nonsensible
conversions that are for the most part a side effect of implementation (100
dogs - 100).

 - big changes in the RFC+patch between last discussions and vote.
 Should not be allowed, can't veto it so voted no

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.  There is absolutely no rule in
the voting RFC that requires a long period of time between the last changes
to the RFC and the vote.  The mandatory discussion period starts ticking
when the RFC is sent to the list, not when the last changes are made to it.
Anyone claiming otherwise is misleading, as both the text in
wiki.php.net/rfc/voting#discussion_period is clear about when the ticking
starts - and on top of that, I can tell you as the person who introduced the
mandatory discussion period and wrote that text, that resetting the clock on
every change to the RFC was never ever even remotely considered or intended
as a requirement.

Zeev

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

Re: [PHP-DEV] Re: Introduce DerOetzi

[Niklas Keller]

You have to input internals@lists.php.net, that changed some time ago.
I've just updated https://wiki.php.net/rfc/howto
See
https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353

Regards, Niklas

2015-03-11 14:43 GMT+01:00 Johannes Ott m...@deroetzi.de:

 Am 11.03.2015 um 14:25 schrieb Christoph Becker:
  Johannes Ott wrote:
 
  BTW:
 
  I'm trying to register a wiki account. But somehow it does not work.
 
  When posting the formular the page is reloading, but nothing else
  happens. No success or no error message is shown.
 
  Maybe I'm doing something wrong?!
 
  Maybe you have not filled out the fourth field (Which email address do
  you have to mail now?) correctly.
 

 I think I have filled correctly all fields, but even if not why is the
 formular not giving any visible information what went wrong?

 I will retry later.

 --
 DerOetzi

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

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Ole Markus With]

On 03/11/2015 09:05 PM, Pierre Joye wrote:
 On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote:

 The vote on the Coercive Scalar Type Hints is now open for voting.



 The latest version of the RFC includes changes discussed on internals@
 last
 week:

 1.  Accept string-bool and int-bool conversions (false-bool is not
 supported)

 2.  Accept leading/trailing spaces in string-number conversions.



 wiki.php.net/rfc/coercive_sth

 wiki.php.net/rfc/coercive_sth#vote
 
 Voted no for the following reasons:
 
 - change default casting, which has been working since years, consistently
 inconsistent
 - due to the previous nature of changes, we have no way to be sure we won't
 break anything badly out there
 - big changes in the RFC+patch between last discussions and vote. Should
 not be allowed, can't veto it so voted no
 

I changed my vote to no for the same reasons.

Cheers,
Ole Markus

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

Re: [PHP-DEV] static constructor

[Patrick Schaaf]

On Thursday 12 March 2015 00:21:34 Johannes Ott wrote:

 The purpose of this suggestion is to introduce a static constructor,
 which is called before the first call to class either static or
 non-static to initialize some static properties which are needed by the
 class.

We are doing this in our private codebase, implemented as a feature of our 
autoloader: after having loaded a class, check whether it has a static method 
called 'init§class()', and call that.

At the moment, 63 of our 397 classes have that, so it's definitely a success 
for us.

One issue to think about, is whether to call that function when it's just 
inherited. We do, and in several places, then check if (get_called_class() == 
__CLASS__). It's a bit tedious in places, but in other places it permits 
setting up of subclass static::$properties from a shared baseclass initializer 
method.

In principle none of that is neccessary, because one can put code outside the 
class definition. One more line to write. In practise, it's a bit annoying, as 
it must go after the whole class definition, or it breaks for subclasses in 
funny ways when the parent class is not already defined...

Something like your version 2 proposal, a new __magic method, would be my 
prefered choice, too.

best regards
  Patrick

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

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

[Patrick ALLAERT]

Le mar. 10 mars 2015 à 21:04, Marcio Almada marcio.w...@gmail.com a
écrit :



 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:

 Hello,

 Le lun. 2 mars 2015 à 00:03, Marcio Almada marcio.w...@gmail.com a
 écrit :


  I'm globally +0.5, however I have some concerns:

 What about constructors?

 Children classes may have a bigger number of arguments for their ctors
 than their parents. Even if not very elegant, it is possible some are
 passing a fixed number of arguments while constructing an object, whether
 that object will take it into account or not.

 Something like:

 class A {
 function __construct($a)
 }

 class B extends A {
 function __construct($a, $b)
 }

 $kind = $bool ? A : B;

 $object = new $kind($foo, $bar);


 I think this is somehow covered here
 https://wiki.php.net/rfc/strict_argcount#hassle_factor, the example is
 not explicit to ctors but the same principles seem to apply. Not sure you
 have a deeper point on it though as PHP is a weirdo and allows constructors
 on interfaces.

 Also, FYI, before we reach discussion phase, there was an idea to ignore
 ctors and other magic methods but you are the first person to bring it up
 on the ML. I'm not very inclined to ignore any other magic methods other
 than *__call* and *__callStatic* for now.


No deep point, just wanted to bring your attention on it.



 E_WARNING:
 -1, IMHO, calling functions/methods with more arguments generally has
 less impact than other aspects that currently generate E_NOTICES (e.g.
 using undefined variables, constants,...). Using an error reporting level
 stronger than for those cases looks inconsistent.


 I disagree with the looks inconsistent part. The E_WARNING option would
 actually be the most consistent with current PHP behavior. Ex:

 function fn($a, $b){}
 fn(1);
 PHP warning:  Missing argument 2 for fn(), called in...

 If we choose E_WARNING both minimum and maximum argument count will have
 the same error level. BTW, in some cases an exceeding argument can be even
 more dangerous than a missing argument.


You have a (debatable) point :)

It depends according to what aspect of PHP your are comparing it with.
Greping zend_error(E_NOTICE,.*) in the code I had the feeling that already
many notices where the sign of a bigger problem than when passing extra
parameters, hence why I suggested E_NOTICE.

My consistency argument was therefore severity based.


 I have no strong feelings regarding to the error level, the E_WARNING vs
 E_NOTICE seems legit so I'm waiting for more opinions.


I wouldn't -1 for E_WARNING because of your extra arguments (sorry for the
pun ;), someone had to do it!). Still in favor of E_NOTICE though.

Patrick

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Zeev Suraski]

 In addition, I'm voting no for the following reasons (in addition to
 Dan's):

 1. It downplays the BC breaks. It says:

  Given the change to the acceptable values into a wide range of
 internal
 functions, this RFC is likely to result in a substantial number of newly
 introduced E_DEPRECATED warnings in internal function invocations,
 although those can be easily suppressed

 So BC breaks are fine, as long as they are *easily suppressed*.
 This is madness, as they won't be able to be suppressed in 8 (when they
 will
 be turned into hard breaks).

If you copied the whole paragraph (one more sentence) instead of it out of
context it would be clear that we're not at all downplaying anything.  We're
portraying it exactly for what it is, for better or worse.
The fact users would have years to adjust is radically different from if we
broke compatibility overnight, and that's exactly what this paragraph
conveys.

 2. It judges the BC breaks based on skeleton applications (Drupal 7's
 stock
 home page, Drupal 7's stock admin interface, Magento's home page,
 Wordpress's home page, ZF2's skeleton app, Symfony's ACME app).
 It doesn't bring up unit tests (which Symfony was shown to have many
 failures). It doesn't show running on non-framework code. It doesn't show
 the average Wordpress/Drupal module for example.

I don't consider Drupal/Magento or WordPress framework code.  It's real
world apps, very very similar to other custom-coded real world apps.

 3. It contains massive misinformation.

   It is our position that there is no difference at all between
 strict and
 coercive typing in terms of potential future AOT/JIT development - none at
 all.

It's our position, the position of people very well versed in this area that
have written a JIT compiler that runs blazingly fast with no type hints at
all.  It's fine that you have a different opinion.  One of us is wrong.

 Yet the JavaScript community is discovering the exact opposite, and is
 looking into a extremely similar dual-mode:
 https://developers.google.com/v8/experiments

This is hardly the exact opposite.  It means something we agreed on from the
get go - if you *change* your code so that the compiler can gain more
insight on what the types are during compile-time (e.g. an explicit cast, or
if we add typed variable declarations) - then sure,  there'll be AOT/JIT
gains - but they're absolutely not coming from the difference in type hints.
I still contend that with coercive type hints we can perform the exact same
static analysis, with just differently phrased output such as  it may need
to be converted rather than will be rejected.   Identical type inference
rules.  Identical everything, just slightly modified text.

 4. It makes claims against the [dual mode
 RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this
 RFC.
 For example:

  Too strict may lead to too lax. In the Dual Mode RFC, when in Strict
 mode, in many cases, functions would reject values that, semantically, are
 acceptable. For example, a “32” (string) value coming back from an integer
 column in a database table, would not be accepted as valid input for a
 function expecting an integer. Since semantically the developer is
 interested
 in this argument-passing succeeding, they would have the choice of either
 removing the integer STH altogether, or, more likely, explicitly casting
 the
 value into an integer. This would have the opposite of the desired outcome
 of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed,
 and
 would happily convert “100 dogs”, “Apples” and even arrays and booleans
 into an integer. Further, since already today, internal functions employ
 coercion rules that are more restrictive than PHP's explicit casting,
 pushing
 people towards explicit casting will actually make things worse in case
 developers opt for explicit casting as they pass values in an internal
 function
 call.

 Yet it completely ignores the fact that the identical situation
 appears with
 the coercive mode RFC. The difference is that with Dual-Mode, it's 100%
 opt-
 in, where with coercive you're forced to add casts.

That's one difference, but the real difference is that the rules are
radically - and the coercive ones are what you'd almost always want to use
in real life, while strict almost never is - which means a lot more explicit
casts.  The most popular conversion in PHP - string - number - just works.
With strict mode, it simply doesn't.   Personally, I think that the 'it
won't break until you actually flip it on' stance is weak.  When people do
flip it on (and they'd certainly be encouraged to do so by many people, e.g.
your blog post from a few weeks ago) - they're going to see massive breakage
which will in turn require massive explicit casting - resulting in much
worse code than in the coercive type hints case.

 5. It's full of logical inconsistencies:

 For example, given the following code:

 function foo(bool 

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Lester Caine]

On 12/03/15 08:29, Zeev Suraski wrote:
 There have been NO big changes to the proposal - only two tweaks which I
 clearly detailed in the Vote email, that have been publicly discussed in
 detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?

I still have to be convinced that adding a half baked variable check
does have a major advantage. YOU have demonstrated the various transfer
paths although they lacked the finer detail type checking that already
happens in many code bases such as the range of the number passed.

The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.

Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

 
 What about inheritance?
 I think dynamic class-constructor would make much more sense.
 A function which can analyse real class and do initialisation.
 
 class A
 {
 protected static function __class_construct()
 {
 echo get_called_class().” class is defined\n;
 }
 }
 
 class B extends A
 {
 }
 
  output 
 A class is defined
 B class is defined
 

I think class-constructor and static-constructor are two different
things. I even think that a inherited class-constructor is a dangerous
thing because you have huge depencies between all subclasses.

For a quick and dirty example:

abstract class A {
protected static $value;

protected static function __class_construct() {
switch (get_called_class()):
   case 'B':
self::$value = 1;
break;
   case 'C':
self::$value = 2;
break;
   default:
self::$value = 3;
}
}

class B extends A {
public static function isOne() {
return self::$value == 1;
}

}

class C extends A {
public static function isTwo() {
return self::$value == 2;
}
}

That not wellformed code for three reasons:

1. Class A must know about all of it's subclasses, so you can not easily
reuse this class A in other projects because you have to refactor the
complete __class_constructor.

2. Huge dependcies between all subclasses. If you want to implement a
class D although extending class A you have to look in each other class
for sideeffects of the the changes you have todo in the
__class_construct for this class D

3. As you can see in the quick example you have a depency of class
loading order as well the result of B::isOne() and C::isTwo() depends in
which order you have loaded your classfiles. Even worst for example
You are using only class B for the beginn B::isOne() giving you true,
later  you load class C for another reason and suddenly B::isOne() gives
you false.

A static constructor however encapsulate the initialization to each
class and should only initialize private members which can be accessed
by protected getters by the subclass.

For the example:


abstract class A {
private static $one;

private static function __static() {
self::$one = 1;
}

protected static function getOne() {
return self::$one;
}
}

class B extends A {
public static function isOne() {
return self::getOne() == 1; //Now always true
}

}

class C extends A {
public static function isTwo() {
return self::getOne() == 2; //Now always false
}
}

Regards,

-- 
DerOetzi

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 05:17 schrieb Levi Morrison:
 On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com 
 wrote:
 On 11/03/2015 23:21, Johannes Ott wrote:

 So now I want to do my first own proposal for a new function in PHP and
 I hope doing it right with starting a discussion here first.

 The purpose of this suggestion is to introduce a static constructor,
 which is called before the first call to class either static or
 non-static to initialize some static properties which are needed by the
 class.


 Can you give an example use case for when this would be useful? I'm
 struggling to think of one for which there isn't already an established
 coding pattern...
 
 Notably, user-land enums. You don't want public constructors because
 you don't want it instantiated except for each enum property. You also
 need it to run on class creation, not afterwards.
 
 I think we'd be better off adding language-level enums than static
 constructors though.
 

Yes indeed user-land enums are one of the use cases I use this feature
at the moment. But there some other use cases as well:

1. Nearly all of my classes have a static LogAdapter $LOG which has to
be intialized with Classname once.

class A {
private static $LOG;

public static function __static() {
self::$LOG = LogAdapter::getLogger(self::class);
}
} A::__static();

The LogAdapter by it selfs although have a __static() method to prepare
the Log4PHP-Framework I'm using.

2. Some Config classes which are intelligent wrapper-classes to some
ini-files and database have to read in some things first.

class Config {

private static $ini;

public static function __static() {
self::$ini = parse_ini_file(...);
// or
// Read from Database

}

} Config::__static();

3. For a multilanguage system I determine the user language by useragent
and fallback to default-language if user language ist not supported.

class Text {
private static $defaultLang;

private static $userLang;

public static function __static() {
self::$defaultLang = //read from Database
self::setUserLanguageOrFallback();
}

private static function setUserLanguageOrFallback() {
...
}
} Text::__static();

4. Already prepare some PDO-statements which needed all over the class

class Example {
   private static $stmts = [];

   public static function __static() {
self::$stmts['select1'] = new DBSelect('SELECT * FROM table WHERE
`col1`=:clause');
   }
} Example::__static();

That are the examples I can found on a quick search over my code.

Regards,

-- 
DerOetzi

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Markus Fischer]

On 11.03.15 22:28, Bob Weinand wrote:
 after all, some people are not happy with the current proposals about scalar 
 types. So, they both still possibly may fail.
 
 Thus, I'd like to come up with a fallback proposal in case both proposals 
 fail:
 
 https://wiki.php.net/rfc/basic_scalar_types
 
 It shouldn't prevent any future improvements and still give use all the 
 advantages of scalar types.

I'm not sure I'm seeing improvements over the other RFCs here ... or I
just missed something obvious. From a quick glance, this one here:

Type declration string and you pass in a bool type.

When in practive the conversion is like this:

$ php -r 'var_dump( (string) false ); var_dump( (string) true );'
string(0) 
string(1) 1

$ php -v
PHP 5.5.9-1ubuntu4.6 (cli) (built: Feb 13 2015 19:17:11)


- Markus

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Arvids Godjuks]

2015-03-12 11:23 GMT+02:00 Zeev Suraski z...@zend.com:

  -Original Message-
  From: Bob Weinand [mailto:bobw...@hotmail.com]
  Sent: Thursday, March 12, 2015 12:46 AM
  To: Pierre Joye
  Cc: PHP internals
  Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
 
  Correct. It's just for the case where the other two fail.
  We still can add strict mode in a later version if people need it.
  All the RFC does is the most basic scalar type hinting you can build
 everything
  on. (for example adding the declare(strict_types=1); would work without
 any
  BC break on top of it)

 The issue is that it's only possible to open the voting on this one until
 tomorrow.

 As I said, I do think we need *something* for 7.0.  I went as far as
 saying that I'd change my vote on the quite-bad-IMHO dual mode RFC to yes
 if it seems both present proposals aren't going to succeed.  But I would
 much rather see this one pass over the dual mode if it was available for a
 vote.

 So really, the options we have are:

 1.  Put this one for a vote before the end of tomorrow.  Here too, on a
 personal level, if I see that this proposal isn't gaining enough votes,
 I'd support the dual mode one.
 2.  Don't put it up for a vote, and then we may or may not have something
 for 7.0.

 Zeev

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


At this point I think the best way is to reserve the keywords for
typehints, and not the only 4, but also for resource and null. And work
towards making typehints in 7.1.
Rushing things like it's now never lead to any good results. And that
dual-mode RFC is re-incarnation of the register_globals, just in a
different way. But essentially will make the same mess.

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-12 4:08 GMT+02:00 Lester Caine les...@lsces.co.uk:

 On 11/03/15 22:44, Yasuo Ohgaki wrote:
  Having namespace for internals would bring much flexibility for API
 changes, both
  OO and procedural API. I may try my best to have consensus.
 
  I think you also like to have OO style API for basic
  variables(int/float/array) as I am.
  Unless we have good/proper procedural API names, it would be an obstacle
 to
  have OO style API for basic variables. I wish you agree to do something
 for it.

 Personally I just want to keep the current name set and so the sheer
 volume of changes proposed is a big kick in the face to me. People are
 talking about the need for an OO based interface, but there has been no
 comment by anybody as to how that should be styled. Having switched
 everything to camelCase as part of the E_STRICT reworking that is
 already well established so while I can see why you want to complete a
 complete switch to underscore padded names THAT is not consistent with
 what everybody else is already using?

 There should not be two naming styles running in parallel and that is
 all I am objecting to. If you get support for this RFC then both an
 extended namespace name set and OO based objects should all follow the
 same rules, and THAT is not what has been happening?

 I think it is equally valid to ask if the current naming guide IS still
 appropriate or if a switch to camelCase for every name space is more
 practical moving forward. In which case dropping the extra underscores
 makes more sense than adding hundreds more! That a name can be written
 all lower case, all upper case or any combination is more a matter of
 choice, but as you say error messages adopt a standard that may not
 match what is in the code anyway?

 --
 Lester Caine - G8HFL


Basically this.

Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one now,
and adding a new subset of it looks pointless. It has it's problems and
legacy, you can't really fix it. Maybe some adjustments are in order to
make it more consistent where it can be done.

I really see only the OO API as a new additional interface. It's part
started by the DateTime, the MySQLi classes and stuff. At this point all
that stuff can be still namespaced, adjusted if needed and continued, just
from the std library first.
I, actually, use _ for function and variable naming and camelCase for
object methods and properties.  To be frank, I like it - it visually
clearly separates the code styles and for the most part the PHP code is
written that way (well, the MySQLi has -num_rows and stuff - i'd change it
to -numRows and so forth).

Arvids.

RE: [PHP-DEV] [RFC] Basic Scalar Types

[Zeev Suraski]

 -Original Message-
 From: Bob Weinand [mailto:bobw...@hotmail.com]
 Sent: Thursday, March 12, 2015 12:46 AM
 To: Pierre Joye
 Cc: PHP internals
 Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types

 Correct. It's just for the case where the other two fail.
 We still can add strict mode in a later version if people need it.
 All the RFC does is the most basic scalar type hinting you can build
everything
 on. (for example adding the declare(strict_types=1); would work without
any
 BC break on top of it)

The issue is that it's only possible to open the voting on this one until
tomorrow.

As I said, I do think we need *something* for 7.0.  I went as far as
saying that I'd change my vote on the quite-bad-IMHO dual mode RFC to yes
if it seems both present proposals aren't going to succeed.  But I would
much rather see this one pass over the dual mode if it was available for a
vote.

So really, the options we have are:

1.  Put this one for a vote before the end of tomorrow.  Here too, on a
personal level, if I see that this proposal isn't gaining enough votes,
I'd support the dual mode one.
2.  Don't put it up for a vote, and then we may or may not have something
for 7.0.

Zeev

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

RE: [PHP-DEV] [RFC] Basic Scalar Types

[Zeev Suraski]

 So really, the options we have are:

 1.  Put this one for a vote before the end of tomorrow.  Here too, on a
 personal level, if I see that this proposal isn't gaining enough votes,
I'd
 support the dual mode one.
 2.  Don't put it up for a vote, and then we may or may not have
something
 for 7.0.

Woops - seems like I was living in the future - there's time to move to a
vote until the 15th, which incidentally is Sunday, not tomorrow.  Thanks
Nikita :)

Zeev

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

Re: [PHP-DEV] Consistent function names

[Lester Caine]

On 12/03/15 09:21, Arvids Godjuks wrote:
 Basically this.
 
 Yasuo asked me some time ago how do I see the new interface, and to be
 frank, I do not see a new procedural api interface at all. We have one
 now, and adding a new subset of it looks pointless. It has it's problems
 and legacy, you can't really fix it. Maybe some adjustments are in order
 to make it more consistent where it can be done.
 
 I really see only the OO API as a new additional interface. It's part
 started by the DateTime, the MySQLi classes and stuff. At this point all
 that stuff can be still namespaced, adjusted if needed and continued,
 just from the std library first.
 I, actually, use _ for function and variable naming and camelCase for
 object methods and properties.  To be frank, I like it - it visually
 clearly separates the code styles and for the most part the PHP code is
 written that way (well, the MySQLi has -num_rows and stuff - i'd change
 it to -numRows and so forth).

This is exactly the same point I've come to ...

That MySQLi example is exactly what I am talking about. I know Postgres
driver has been 'underscored' but it is THAT which is out of sync with
the rest of the code base. interbase driver has the same problem, and we
will need to bring in fbird_ to replace ibase_ there, but I use ADOdb
almost exclusively which has been CamelCase since day one ( all be it
with a leading capital ). PDO is camelCase but that has other problems ;)

If there has to be any tidy up, like you, I think switching back to
loose some underscores is the less painful option.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

Hey PHP Internals,

So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure why
people are against it - and no one seems to want to debate it either.

From pre-RFC discussions, two main concerns were raised:
1. This will promote the creation of poor code.
2. The proposed semantics of empty() is wrong. It should be equivalent to 
logically
AND'ing empty()'s arguments together - just like with isset().

To readdress these two points:

1.
Any feature that reduces the amount of written code can be said to make it
easier to write code - regardless of whether this is good or bad code. That
part is up to the developer.

Perhaps the examples in my RFC do not portray this feature in the best of
lights - they were simply meant to show the more extreme usages of empty()
in popular, real-world codebases. So let me provide some statistics.

I ran the following egrep on a number of CMSs (the regular expression used isn't
perfect, but it still gives some sort of approximation):

egrep -rio '(empty\(.*\) *(\|\| *empty\(.*\))+)|(!empty\(.*\) *( 
*!empty\(.*\))+)' project_dir/ | wc -l

Results:
WordPress: 50
OpenCart: 22
phpbb: 36
Drupal: 74
SMF2.1: 266
Joomla: 23

So the proposed short-hand notation of empty() in this RFC does have its
usages. Just as a full disclaimer though, framework codebases will not see
this same usefulness since they don't handle business-specific validation logic
on input fields, web service data, etc (which seems like the predominant usage
of multiple empty()'s in a single condition).


2.
The falsy semantics of empty() means that inlining its behaviour to exactly 
match
isset() isn't logical.

For example, we can roughly assert that `empty() = ! isset()`. This holds true
with the current semantics proposed by this RFC:

$defined = 1;
// $undefined;
var_dump(empty($defined, $undefined) === ! isset($defined, $undefined)); // 
bool(true)

If empty()'s arguments were logically AND'ed together, then the above assertion 
would
not hold true.


So those are the two arguments I'm aware of - if anyone in the -1 camp has any
other reasons, then please do raise them!

Thanks,
Tom

 Hello PHP Internals!

 I'd like to put the variadic empty() RFC to vote.

 RFC: https://wiki.php.net/rfc/variadic_empty

 Voting will finish in 14 days time on March 21st.

 Thanks,
 Tom

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

Re: [PHP-DEV] Consistent function names

[Lester Caine]

 Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
 pgBlah() ? 

It was that extra underscores having been added to the pg_ functions is
being put forward as a reason for adding them everywhere else. That is
perhaps when this discussion should have been undertaken, but someone
making their prefered driver look how they want is not a good reason for
pushing that everywhere else?

 If that's the case - why? For procedural API that's totaly fine. As I
 said, I think the functions with _ word separator are totaly fine and
 it's really no need to change that.

Totally agree.

 The OO interface, that needs to be build eventually, that one should use
 camelCase for all the methods and properties.
 This way the code style clearly separates the OO inteface and the
 procedural interface. And I think it's good. At least it served me well
 all my 10+ years with PHP.

We are on the same hymn sheet ...
First choice ... leave things alone

Ysuo seems intent on 'consistency fixes' though so my second preference
if it HAS to happen is simply to reduce the number of underscores

 (well, the MySQLi has -num_rows and stuff - i'd change it to -numRows and 
 so forth)
as an example of what works better in line with current practice elsewhere?

Current RFC is over the top.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] static constructor

[Crypto Compress]

Hello Johannes,

class Foo {
private static function __static() {
throw new Exception(boom);
}
}

while(true) {
try {
$foo = new Foo;
} catch (Exception ex) {}
}

Would this code be valid?

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

Re: [PHP-DEV] Consistent function names

[Arvids Godjuks]

2015-03-12 11:41 GMT+02:00 Lester Caine les...@lsces.co.uk:

 On 12/03/15 09:21, Arvids Godjuks wrote:
  Basically this.
 
  Yasuo asked me some time ago how do I see the new interface, and to be
  frank, I do not see a new procedural api interface at all. We have one
  now, and adding a new subset of it looks pointless. It has it's problems
  and legacy, you can't really fix it. Maybe some adjustments are in order
  to make it more consistent where it can be done.
 
  I really see only the OO API as a new additional interface. It's part
  started by the DateTime, the MySQLi classes and stuff. At this point all
  that stuff can be still namespaced, adjusted if needed and continued,
  just from the std library first.
  I, actually, use _ for function and variable naming and camelCase for
  object methods and properties.  To be frank, I like it - it visually
  clearly separates the code styles and for the most part the PHP code is
  written that way (well, the MySQLi has -num_rows and stuff - i'd change
  it to -numRows and so forth).

 This is exactly the same point I've come to ...

 That MySQLi example is exactly what I am talking about. I know Postgres
 driver has been 'underscored' but it is THAT which is out of sync with
 the rest of the code base. interbase driver has the same problem, and we
 will need to bring in fbird_ to replace ibase_ there, but I use ADOdb
 almost exclusively which has been CamelCase since day one ( all be it
 with a leading capital ). PDO is camelCase but that has other problems ;)

 If there has to be any tidy up, like you, I think switching back to
 loose some underscores is the less painful option.

 --
 Lester Caine - G8HFL


Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
pgBlah() ?
If that's the case - why? For procedural API that's totaly fine. As I said,
I think the functions with _ word separator are totaly fine and it's really
no need to change that.
The OO interface, that needs to be build eventually, that one should use
camelCase for all the methods and properties.
This way the code style clearly separates the OO inteface and the
procedural interface. And I think it's good. At least it served me well all
my 10+ years with PHP.

Arvids.

Re: [PHP-DEV] static constructor

[Crypto Compress]

Am 12.03.2015 um 12:33 schrieb Johannes Ott:

Am 12.03.2015 um 12:16 schrieb Crypto Compress:

Hello Johannes,

class Foo {
 private static function __static() {
 throw new Exception(boom);
 }
}

while(true) {
 try {
 $foo = new Foo;
 } catch (Exception ex) {}
}

Would this code be valid?

Have to think about this issue, but on the first look I would say yes!

Because the meaning of the static constructor is to do some necassary
initialize for the class it should be able to throw an Exception if it
cannot do it's work correctly. For example if it needs to read some
configuration from a Database and is not able to connect.

For the caller I although would say, that the error inside the static
constructor should be catchable, for the simple fact that every Error
should be catchable for user-errorhandling.

What is your point of view for this? I'm open for discussion about this.

Regards


If it's valid code then caching thrown exception and rethrow as 
wrapped-inner-exception on each subsequent access on Foo, seems 
feasible. I like the idea but cannot wrap my head around this.


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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Johannes Ott wrote on 12/03/2015 08:54:

Am 12.03.2015 um 05:17 schrieb Levi Morrison:

On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com wrote:

On 11/03/2015 23:21, Johannes Ott wrote:

So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.

The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are needed by the
class.


Can you give an example use case for when this would be useful? I'm
struggling to think of one for which there isn't already an established
coding pattern...

Notably, user-land enums. You don't want public constructors because
you don't want it instantiated except for each enum property. You also
need it to run on class creation, not afterwards.

I think we'd be better off adding language-level enums than static
constructors though.


Yes indeed user-land enums are one of the use cases I use this feature
at the moment. But there some other use cases as well:


Most of these examples are just crying out to be real objects, not 
static classes. You might not want to be creating them every time you 
use them, but that's what patterns like Singletons and Dependency 
Injection are for.




1. Nearly all of my classes have a static LogAdapter $LOG which has to
be intialized with Classname once.

class A {
 private static $LOG;

 public static function __static() {
 self::$LOG = LogAdapter::getLogger(self::class);
 }
} A::__static();

The LogAdapter by it selfs although have a __static() method to prepare
the Log4PHP-Framework I'm using.


This particular example could be achieved with a static getLogger() 
method, which does the initialisation check the first time the logger is 
needed, rather than the first time class A is needed.



To my mind, the creation of a class in memory should not have 
side-effects - you should be able to assume that all your classes exist 
at the same time, before any of your code runs. The only justification 
for not acting that way would be Python-style metaclasses, where the 
creation of a class definition was the responsibility of some other 
object, and that's a power to be wielded very carefully.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Safe execution timeout handling

[Dan Ackroyd]

On 11 March 2015 at 21:44, Dmitry Stogov dmi...@zend.com wrote:
 Hi,

 Improvement ideas are welcome...


Hi Dmitry,

The idea was raised before of having both soft and hard limits for the
memory consumption and time limits, and to trigger a user defined
callback when the soft limit was reached.

This would be beneficial in a couple of ways.

i) It allows people to detect that their application is consuming more
memory/time than they would like, but not enough to cause stability
issues. This would be useful in production where you don't want to
make a request fail unless you absolutely have to.

ii) It allows them to decide exactly what action to take. Sometimes
it's fine to terminate requests straight away, other times people
would want to do some cleanup before terminating.

Additionally being able to call gc_collect_cycles() in the callback
would sometimes release enough memory to bring the memory used to back
under the soft limit and so allow processing to continue. Ironically,
this seems to be an issue when writing efficient PHP code. Due to the
way the garbage collector only collects cycles rarely, if you have
very large variables compared to typical code, you can easily
encounter a situation where the total memory that is still being
referenced is small, but there is still a huge amount being held in
cycles.

The code below shows this happening:
With gc_collect_cycles called: peak memory = 786kB
Without gc_collect_cycles called: Allowed memory size of 67108864
bytes exhausted

i.e. 95% of memory allocated isn't being used and could be freed, but
hasn't because the number of GC objects didn't reach 10,000 and so the
gc_collect_cycles didn't kick in automatically.

cheers
Dan



?php


$performGC = false;

if ($performGC) {
echo GC collection will be done - app should not crash.\n;
}
else {
echo GC collection won't be done - app should crash.\n;
}
$dataSizeInKB = 128;

//Change this line if you tweak the parameters above.
ini_set('memory_limit', 64M);

$memData = '';

for ($y=0 ; $y$dataSizeInKB ; $y++) {
for ($x=0 ; $x32 ; $x++) { //1kB
$memData .= md5(time() + (($y * 32) + $x));
}
}

file_put_contents(memdata.txt, $memData);

// This function creates a cyclic variable loop
function useSomeMemory($x) {
$data = [];
$data[$x] = file_get_contents(memdata.txt);
$data[$x + 1] = $data;
};


for($x=0 ; $x1000 ; $x++) {
useSomeMemory($x);
if ($performGC == true) {
gc_collect_cycles();
}
}

printf(
\nused: %10d | allocated: %10d | peak: %10d\n,
memory_get_usage(),
memory_get_usage(true),
memory_get_peak_usage(true)
);

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

Re: [PHP-DEV] php_stream_read(...) may return less than expected

[Michael Wallner]

On 12/03/15 14:28, Umberto Salsi wrote:
 Hi all,
 I'm not a PHP internals developer, but this might be a bug spread here and
 there in the source. This coding pattern:
 
 if(php_stream_read(..., n) != n){
 php_error_docref(NULL TSRMLS_CC, E_SOMETHING, Read error!);
 
 seems wrong to me because there might be streams that returns less than
 n bytes at once. When exactly n bytes are expected, not more not less,
 a function similar to this one should be used instead:
 
 int php_stream_read_fully(..., int n){
   continue calling php_stream_read() until exactly n bytes are
 collected, or a premature EOF, or I/O error
 }
 
 I ran into this issue passing a custom stream to getimagesize():
 
 getimagesize(myprotocol://);
 
 where myprotocol:// may, in some situations, return less bytes than
 expected (see the http://php.net/manual/en/class.streamwrapper.php
 wrapper class, stream_read() method). Looking at the implementation of
 this function in ext/standard/image.c, I just found the pattern above.
 If this is really a bug, many other functions might be affected.

Why does your stream behave non-blocking by default? Unless explicitly
stated, those callees probably expect a blocking stream.


-- 
Regards,
Mike

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

[PHP-DEV] php_stream_read(...) may return less than expected

[Umberto Salsi]

Hi all,
I'm not a PHP internals developer, but this might be a bug spread here and
there in the source. This coding pattern:

if(php_stream_read(..., n) != n){
php_error_docref(NULL TSRMLS_CC, E_SOMETHING, Read error!);

seems wrong to me because there might be streams that returns less than
n bytes at once. When exactly n bytes are expected, not more not less,
a function similar to this one should be used instead:

int php_stream_read_fully(..., int n){
continue calling php_stream_read() until exactly n bytes are
collected, or a premature EOF, or I/O error
}

I ran into this issue passing a custom stream to getimagesize():

getimagesize(myprotocol://);

where myprotocol:// may, in some situations, return less bytes than
expected (see the http://php.net/manual/en/class.streamwrapper.php
wrapper class, stream_read() method). Looking at the implementation of
this function in ext/standard/image.c, I just found the pattern above.
If this is really a bug, many other functions might be affected.

Regards,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it


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

Re: [PHP-DEV] static constructor

[Johannes Ott]

 
 Most of these examples are just crying out to be real objects, not
 static classes. You might not want to be creating them every time you
 use them, but that's what patterns like Singletons and Dependency
 Injection are for.
 

I really disagree to this. Singletons are a typical FactoryPattern, none
of the examples except the LogAdapter itself are doing implementation of
a factory. They are just initialize some computed static variables once
in the live time of the class mostly for internal usage of the class.
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.

In use case 1 Dependency Injection maybe another solution but does not
exactly do what I want to do.

 
 1. Nearly all of my classes have a static LogAdapter $LOG which has to
 be intialized with Classname once.

 class A {
  private static $LOG;

  public static function __static() {
  self::$LOG = LogAdapter::getLogger(self::class);
  }
 } A::__static();

 The LogAdapter by it selfs although have a __static() method to prepare
 the Log4PHP-Framework I'm using.
 
 This particular example could be achieved with a static getLogger()
 method, which does the initialisation check the first time the logger is
 needed, rather than the first time class A is needed.
 

yes that would be another valid pattern. And would be prefered for me if
I use the Logger in 1 or 2 out of 10 class methods, which are not used
very often. But mostly I'm using it in 9 or 10 of 10 methods, which are
invoked several times through lifetime. So doing a null check each time
is a overhead of calculation which can be avoided with this static
constructor pattern.

 
 To my mind, the creation of a class in memory should not have
 side-effects - you should be able to assume that all your classes exist
 at the same time, before any of your code runs. 


I agree the real creation(/parsing) of the class should have no
side-effects. But the static constructor is not executed at the
creation-time of the class but directly before first access on the
class. That are two totally different moments in the lifecycle of the
class and does not block the possibility to first read all classes
without any side-effects.

 The only justification
 for not acting that way would be Python-style metaclasses, where the
 creation of a class definition was the responsibility of some other
 object, and that's a power to be wielded very carefully.
 

The static constructor or sometimes although called class constructor is
a well known OOP-pattern implemented by different languages like C#
or Java.

Regards,

-- 
DerOetzi

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

[PHP-DEV] Drop Multiply VM kind support

[Xinchen Hui]

Hey:

 We have CALL SWITCH GOTO vm kind supports for long time.

 And we use CALL for default.

 SWITCH GOTO seems useless now, and brings us some troubles while
maintaining .

 And also could make some extension unable to work, like in phpdbg:

  PHPDBG_G(vmret) = execute_data-opline-handler(execute_data);


 So, maybe it's time for us to remove GOTO and SWITCH at all?

 thanks

-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Andi Gutmans]

 On Mar 11, 2015, at 2:28 PM, Bob Weinand bobw...@hotmail.com wrote:
 
 Hi all,
 
 after all, some people are not happy with the current proposals about scalar 
 types. So, they both still possibly may fail.
 
 Thus, I'd like to come up with a fallback proposal in case both proposals 
 fail:
 
 https://wiki.php.net/rfc/basic_scalar_types
 
 It shouldn't prevent any future improvements and still give use all the 
 advantages of scalar types.

Agree and I would vote +1 on this even if I'd prefer coercive. 
It is a very valid option for a 7.0 and it is future proof. 

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

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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Johannes Ott wrote on 12/03/2015 14:51:

That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.


I agree, but as such, I think that method should be called somewhere by 
the code, even if only by a DI container, not happen automagically and 
slurp in data from global state.


Consider your prepare some SQL queries example - it has a dependency 
on a database connection, so that now has to be global state; if that in 
turn is lazily initialised, it needs to get the connection string from 
yet more global state, and so on. By using the class constructor, you 
are forced to hard-code those dependencies - there's no parameters to 
pass them in, and you can't pre-initialise them from outside the class, 
because nothing on the class can run before the class constructor.




So doing a null check each time
is a overhead of calculation which can be avoided with this static
constructor pattern.


Presumably the engine would need to perform some implicit equivalent of 
if ( ! self::$initialised ) on each call to decide if the static 
constructor needs to be called or not, so the overhead is not completely 
eliminated.




I agree the real creation(/parsing) of the class should have no
side-effects. But the static constructor is not executed at the
creation-time of the class but directly before first access on the
class. That are two totally different moments in the lifecycle of the
class and does not block the possibility to first read all classes
without any side-effects.


OK, I misunderstood this part. So this is like the private constructor 
of a Singleton, a lazy initialisation the first time you use it. (Sorry 
to bang on about Singletons; they're what I know, so I'm trying to 
understand the similarities and differences.)



Incidentally, note that a recent RFC to add the ability to declare a 
class as static failed by 12 votes to 5 - 
https://wiki.php.net/rfc/abstract_final_class - and much of the 
discussion was around static implementations being generally inferior to 
instances, so I'm not alone in challenging designs that rely on them.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 12:40 schrieb Niklas Keller:

 
 How would it behave for the second call? If the first initialize fails due
 to some exception, should that static constructor be executed again?
 

I think there a two different solutions and I do not know which one I
prefer at the moment:

1. No second call can raise an fatal.

2. Yes should be executed again

As an internal implementation, we can do a flag which is at creation
time of class false and set after sucessful run of the static
constructor to true.

Do avoid deadlocks in loops like in the example maybe we can implement a
combination of both solutions. We can implement the flag not as a
boolean but as an integer counter. Raising a FATAL after X retries.

Regards,
-- 
DerOetzi

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

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Derick Rethans]

On Thu, 12 Mar 2015, Thomas Punt wrote:

 Hey PHP Internals,
 
 So there hasn't been much discussion on this RFC, and yet a lot of people have
 voted -1 on it. This is a little disappointing because I'm not entirely sure 
 why
 people are against it - and no one seems to want to debate it either.

IMO, because it's not obvious whether it is *all* empty, or *atleast 
one* empty. The same argument we had before, when we expanded isset() to 
be variadic. We had the same discussion then, resulting on keeping 
empty() as it is. 

One discussion 11 years ago:
http://marc.info/?l=php-internalsm=109836951711930

I can't find the discussion prior to that though.

cheers,
Derick

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

Re: [PHP-DEV] static constructor

[Patrick Schaaf]

Am 12.03.2015 17:28 schrieb Larry Garfield la...@garfieldtech.com:

 I thought it sounded familiar.  Also check the list archive for A modest
proposal: __constructStatic from a month ago.  It was rejected then, too.

That proposal was about a completely different issue.

But you are right, it was dismissed using the same I don't like static,
use objects nonargument.

best regards
  Patrick

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Larry Garfield]

On 3/12/15 4:11 AM, Lester Caine wrote:

On 12/03/15 08:29, Zeev Suraski wrote:

There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago.


Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?


Code with type hints won't be valid on PHP 5 period, no matter what 
approach we take.


Making internal functions pickier about their existing typing doesn't 
make writing PHP5-compatible code impossible, it just means you have to 
be more careful about weird and probably-buggy cases like 
number_format(101 dalmatians).  As Zeev noted, most of the places that 
these changes caused an issue are likely existing bugs in the first 
place, so the PHP 5 code would become better by being PHP 7-compatible.



The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.


We don't lose anything by type information moving from a docblock to the 
method signature itself, and in fact we gain a great deal as has been 
discussed to death in this thread.  We already can have whatever type 
information you want in docblocks, but that means diddlysquat for the 
compiler or runtime.  This whole paragraph is a red herring.



Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?


With an opcache built into core and discussion of it moving into the 
engine I think that's a given, in practice. That's entirely unrelated to 
typing, though.


--Larry Garfield

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 16:57 schrieb Rowan Collins:
 Johannes Ott wrote on 12/03/2015 14:51:
 That is nearly like initializing a class constant, but in my opinion a
 constant should not have a complex algorithm (For example conditions
 or read from filesystem). That should be encapsulated inside a proper
 method body.
 
 I agree, but as such, I think that method should be called somewhere by
 the code, even if only by a DI container, not happen automagically and
 slurp in data from global state.
 

It is called somewhere in the code namely inside the static constructor :D

 Consider your prepare some SQL queries example - it has a dependency
 on a database connection, so that now has to be global state; if that in
 turn is lazily initialised, it needs to get the connection string from
 yet more global state, and so on. By using the class constructor, you
 are forced to hard-code those dependencies - there's no parameters to
 pass them in, and you can't pre-initialise them from outside the class,
 because nothing on the class can run before the class constructor.
 

Okay that is a point each developer should be aware and decide by his self.

 So doing a null check each time
 is a overhead of calculation which can be avoided with this static
 constructor pattern.
 
 Presumably the engine would need to perform some implicit equivalent of
 if ( ! self::$initialised ) on each call to decide if the static
 constructor needs to be called or not, so the overhead is not completely
 eliminated.
 
Yes you are right but I think it can be done more efficiently inside the
interpreter using some struct flags then have to parse each time inside
a coded part in the application.

 Incidentally, note that a recent RFC to add the ability to declare a
 class as static failed by 12 votes to 5 -
 https://wiki.php.net/rfc/abstract_final_class - and much of the
 discussion was around static implementations being generally inferior to
 instances, so I'm not alone in challenging designs that rely on them.
 

I will check the rfc later but static class sounds strange.

 Regards,


Regards,
-- 
DerOetzi

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

Re: [PHP-DEV] static constructor

[Alexey Zakhlestin]

 On 12 Mar 2015, at 19:28, Larry Garfield la...@garfieldtech.com wrote:
 
 I thought it sounded familiar.  Also check the list archive for A modest 
 proposal: __constructStatic from a month ago.  It was rejected then, too.
 
 Really, I cannot think of any cases where I want to have a static class 
 self-initialize with global data (because all statics are just globals with a 
 fancy dress) where I wouldn't slap myself for being stupid and not just 
 making a proper object, factory, DI, or any number of other options are are 
 10x more testable and reusable and verifiable.  Sure there's places you could 
 use it; there's just much better options already available in the language 
 and have been for a decade.

I guess it’s just “dreaming” about classes, which are first-class citizens, 
like in smalltalk/ruby/python :-)
But this is just an approximation, anyway.

Real class-objects probably would never happen in PHP.

-- 
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





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

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Lester Caine]

On 12/03/15 16:55, Larry Garfield wrote:
 On 3/12/15 4:11 AM, Lester Caine wrote:
 On 12/03/15 08:29, Zeev Suraski wrote:
 There have been NO big changes to the proposal - only two tweaks which I
 clearly detailed in the Vote email, that have been publicly discussed in
 detail on internals@ more than a week ago.

 Zeev ... being realistic I think that the chances of getting another 48
 votes in favour are unlikely as are the chances of blocking the other
 proposal?

 The problem here is that a large number of people want type hinting one
 way or another and there is not a strong enough case being made NOT to
 bow to that will? So the next problem is perhaps how do we live with a
 section of the developer world adding hints to well established
 libraries? During the move to PHP5 one could quite happily write code
 that continued to work on the majority of PHP4 systems, The move to PHP7
 needs the same set of guidelines, so what is currently being championed
 which will mean that we have to maintain a PHP5 version of a library
 from day one of PHP7 and what do we avoid in order for PHP code still to
 run on PHP5?
 
 Code with type hints won't be valid on PHP 5 period, no matter what
 approach we take.
 
 Making internal functions pickier about their existing typing doesn't
 make writing PHP5-compatible code impossible, it just means you have to
 be more careful about weird and probably-buggy cases like
 number_format(101 dalmatians).  As Zeev noted, most of the places that
 these changes caused an issue are likely existing bugs in the first
 place, so the PHP 5 code would become better by being PHP 7-compatible.

If type hinting is NOT used at all, then the code should run on PHP5?
The question is just what does one have to avoid to remain PHP5
compatible, and more important just how does one avoid some third party
use of it getting in the way.

 The bit I am more concerned about is the further dilution of the
 docblock annotation as people will adopt type hints in place of the
 already existing annotation and again we loose a lot more than we gain
 :( Personally I would much prefer that this was picked up properly again
 as other RFC's are trying to do, and I feel that answers all of the type
 hinting ad other static analysis problems that some people seem to think
 are so important. Expansion of the docblock 'standard' will also allow
 range of variables to be managed, yet the whole lot can be striped and
 ignored once one is out of 'design' phase.
 
 We don't lose anything by type information moving from a docblock to the
 method signature itself, and in fact we gain a great deal as has been
 discussed to death in this thread.  We already can have whatever type
 information you want in docblocks, but that means diddlysquat for the
 compiler or runtime.  This whole paragraph is a red herring.

The whole argument about adding type hinting revolves about red
herrings. There is nothing stopping someone using static analysis on
well written and documented PHP5 code today without affecting everybody
elses use of that code.

 Is the final endpoint target here that like python, PHP will become a
 two stage process with compiled versions of user land code?
 
 With an opcache built into core and discussion of it moving into the
 engine I think that's a given, in practice. That's entirely unrelated to
 typing, though.

Again much is being made of 'optimizing at compile time' a term which I
simply don't recognise. If one has a script that is running ... it's
running ... and loading it up with more switches is detracting from
performance ... unless there is caching already running?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Johannes Ott wrote on 12/03/2015 17:05:

Am 12.03.2015 um 16:57 schrieb Rowan Collins:

Johannes Ott wrote on 12/03/2015 14:51:

That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.

I agree, but as such, I think that method should be called somewhere by
the code, even if only by a DI container, not happen automagically and
slurp in data from global state.


It is called somewhere in the code namely inside the static constructor :D


What I meant is that it is not executed by any piece of code the user 
writes, but directly by the engine based on a magic hook.




So doing a null check each time
is a overhead of calculation which can be avoided with this static
constructor pattern.

Presumably the engine would need to perform some implicit equivalent of
if ( ! self::$initialised ) on each call to decide if the static
constructor needs to be called or not, so the overhead is not completely
eliminated.


Yes you are right but I think it can be done more efficiently inside the
interpreter using some struct flags then have to parse each time inside
a coded part in the application.


Yes, point taken.



Incidentally, note that a recent RFC to add the ability to declare a
class as static failed by 12 votes to 5 -
https://wiki.php.net/rfc/abstract_final_class - and much of the
discussion was around static implementations being generally inferior to
instances, so I'm not alone in challenging designs that rely on them.


I will check the rfc later but static class sounds strange.


Basically, all your examples imply classes that consist only of static 
members - they're not using static helpers to create instances, they're 
using them *instead of* instances. This was what was mean by static 
class in that proposal. Personally, I was in favour of that, since I 
think such classes do exist, and a syntax for declaring them would be 
useful, but the most common argument against was that we should be 
finding ways for people to not need such classes, rather than supporting 
them better. This proposal sounds like it's adding facilities to classes 
that belong on objects, or ... somewhere else.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Johannes Ott wrote on 12/03/2015 19:45:

  All of the magic methods are doing like this.


I thought you might say that, but the only thing remotely similar I can 
think of is a destructor, which gets called when an object goes out of 
scope; the others are all the implementation of, or instead of, some 
specific piece of code:

__construct() runs every time for new Foo
__get() and __set() runs every time for property access with - on an 
undefined property
__call() and __callStatic() runs every time for method access on an 
undefined property


The difference with this is that you never know which part of your code 
will actually trigger it, because it only runs some of the time.




Okay thats a point I have to clearify I see, maybe my examples where to
much shorten by me. In my examples I'm showing only the initialize parts
of the classes, the initialized properties are used all over the class
in static as well in non-static context.


OK, so these are classes which share certain resources between all 
instances, represented by these static properties. In that case, would 
it be reasonable to say that the initialization of these properties 
needs to happen the first time an instance is created? If so, the 
if(self::$initialized) check needs to run only as often as 
__construct(), not every time any method is called.


If the static methods are public, and used for something other than 
managing instances (Factory / Singleton / etc), then are they really the 
responsibility of the same class? i.e. do you have a Utility class 
hiding in there pretending to be part of the instance/factory class?




For use case 1 the LogAdapter for example is a singleton instance per
class, that's why in my understanding of dependcy Injection it is not
working with it (correct me please if I'm wrong). And this singleton is
used to log in all methods of the class/object.


In a system using Dependency Injection, all dependencies have to be 
passed in somewhere; a static dependency could be injected into a static 
property by a static method, but it still has to come from somewhere. 
Your implementation is pulling it from a global variable (or a public 
static, which is effectively the same thing) rather than waiting for it 
to be provided.


Note also that you don't need to create 5 loggers just because you have 
5 objects needing a logger - you pass in (or acquire from a global 
variable) references to the same instance each time - so the fact that 
it's an instance property rather than a static one is really no hardship.


public function __construct() {
$this-logger = LogAdapter::getLogger(self::class);
}



Surely I would be able to get the specializied Singleton instance with
doing some code like the following two examples:
[examples trimmed]


If not using any injection, I would implement it as follows:

class A {

   private static $LOG;

   private static function getLogger() {
  if (self::$LOG = null) {
  self::$LOG = LogAdapter::getLogger(self::class);
  }
  return self::$LOG;
  }

   public static function a() {
  self::getLogger()-debug();
  
  self::getLogger()-error();
   }

   public function b() {
  ...
  self::getLogger()-error();
   }

   ...

}


Not much more verbose than your version with __static, but a lot less 
magic, and therefore easier to debug. Slightly worse performance, with 
the extra method call, but I doubt if it would add up to enough to worry 
about.


Thinking about it, you could even leave the way open for a different 
strategy by using $this-getLogger() instead of self::getLogger() - 
right now, that's 100% equivalent, but it makes it easier to change 
later to use injection, or be able to override the logger on particular 
instances, etc.


This is often the problem with magic methods, be they at the language 
level or in a framework: they tend to lock you into working in a 
particular way, where more explicit code can be more readily refactored.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] static constructor

[Larry Garfield]

On 3/12/15 10:57 AM, Rowan Collins wrote:

Johannes Ott wrote on 12/03/2015 14:51:

That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.


I agree, but as such, I think that method should be called somewhere by
the code, even if only by a DI container, not happen automagically and
slurp in data from global state.

Consider your prepare some SQL queries example - it has a dependency
on a database connection, so that now has to be global state; if that in
turn is lazily initialised, it needs to get the connection string from
yet more global state, and so on. By using the class constructor, you
are forced to hard-code those dependencies - there's no parameters to
pass them in, and you can't pre-initialise them from outside the class,
because nothing on the class can run before the class constructor.



So doing a null check each time
is a overhead of calculation which can be avoided with this static
constructor pattern.


Presumably the engine would need to perform some implicit equivalent of
if ( ! self::$initialised ) on each call to decide if the static
constructor needs to be called or not, so the overhead is not completely
eliminated.



I agree the real creation(/parsing) of the class should have no
side-effects. But the static constructor is not executed at the
creation-time of the class but directly before first access on the
class. That are two totally different moments in the lifecycle of the
class and does not block the possibility to first read all classes
without any side-effects.


OK, I misunderstood this part. So this is like the private constructor
of a Singleton, a lazy initialisation the first time you use it. (Sorry
to bang on about Singletons; they're what I know, so I'm trying to
understand the similarities and differences.)


Incidentally, note that a recent RFC to add the ability to declare a
class as static failed by 12 votes to 5 -
https://wiki.php.net/rfc/abstract_final_class - and much of the
discussion was around static implementations being generally inferior to
instances, so I'm not alone in challenging designs that rely on them.

Regards,


I thought it sounded familiar.  Also check the list archive for A 
modest proposal: __constructStatic from a month ago.  It was rejected 
then, too.


Really, I cannot think of any cases where I want to have a static class 
self-initialize with global data (because all statics are just globals 
with a fancy dress) where I wouldn't slap myself for being stupid and 
not just making a proper object, factory, DI, or any number of other 
options are are 10x more testable and reusable and verifiable.  Sure 
there's places you could use it; there's just much better options 
already available in the language and have been for a decade.


--Larry Garfield

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

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

Hey Dan,

 The falsy semantics of empty() means that inlining its behaviour to exactly 
 match
 isset() isn't logical.

 The problem isn't so much that the behaviour doesn't match some other
 pattern in PHP; the problem is that the function doesn't do what its
 name says it does.

 if any arguments passed into empty() are considered falsy, then true
 will be returned

 i.e. it doesn't check whether the arguments are 'empty', it's checking
 whether they are 'all set and not falsy'. Having a function do
 something different to what it's name suggests will lead to it being
 used incorrectly a lot of the time.

Yes, I think this is probably the discursive area that is causing a divide in 
vote.
The only compromise I can think of (though not sure on its feasibility) would be
to have a flag as the last parameter that defaulted to logically AND'ing its 
args
with the ability to switch the semantics to logically OR the args.

 The other reason I voted no, is that I just don't think this adds
 enough to the language to be implemented in core. For at least two of
 the examples in the RFC the desired functionality could be implemented
 in userland.

 The size of the PHP core codebase is already unwieldy. I think any
 suggested addition needs to have a clear advantage over being
 implemented in userland

I could understand this POV if it caused a lot of changes, but the patch is
pretty simple a small. I think the potential benefits brought by this feature
is worth its weight against 10 lines of additional code in the language grammar
file.

 cheers
 Dan

Thanks for reclarifying the issues you have with this RFC.

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 18:55 schrieb Rowan Collins:
 Johannes Ott wrote on 12/03/2015 17:05:
 Am 12.03.2015 um 16:57 schrieb Rowan Collins:
 Johannes Ott wrote on 12/03/2015 14:51:
 That is nearly like initializing a class constant, but in my opinion a
 constant should not have a complex algorithm (For example conditions
 or read from filesystem). That should be encapsulated inside a proper
 method body.
 I agree, but as such, I think that method should be called somewhere by
 the code, even if only by a DI container, not happen automagically and
 slurp in data from global state.

 It is called somewhere in the code namely inside the static
 constructor :D
 
 What I meant is that it is not executed by any piece of code the user
 writes, but directly by the engine based on a magic hook.
 

Yes but thats why it is called magic method, isn't it ;) No serious if
it is clearly defined what the magic method __static() does and when it
is invoked, it should be okay. All of the magic methods are doing like this.

 Incidentally, note that a recent RFC to add the ability to declare a
 class as static failed by 12 votes to 5 -
 https://wiki.php.net/rfc/abstract_final_class - and much of the
 discussion was around static implementations being generally inferior to
 instances, so I'm not alone in challenging designs that rely on them.

 I will check the rfc later but static class sounds strange.

I had time to read the linked rfc now. If I understand it right that rfc
Means a Util-class-pattern for util-classes which should not be
extendable. I don't see the sense of that now, why I util class with
only static methods which typically is defined as abstract should not be
extendable by other, I cannot remember to have this use cased in my 15
years of OOP-programming but okay maybe there are such use cases. But my
proposal is another one see my next comment on your comment below.

 
 Basically, all your examples imply classes that consist only of static
 members - they're not using static helpers to create instances, they're
 using them *instead of* instances. This was what was mean by static
 class in that proposal. Personally, I was in favour of that, since I
 think such classes do exist, and a syntax for declaring them would be
 useful, but the most common argument against was that we should be
 finding ways for people to not need such classes, rather than supporting
 them better. This proposal sounds like it's adding facilities to classes
 that belong on objects, or ... somewhere else.
 

Okay thats a point I have to clearify I see, maybe my examples where to
much shorten by me. In my examples I'm showing only the initialize parts
of the classes, the initialized properties are used all over the class
in static as well in non-static context.

For use case 1 the LogAdapter for example is a singleton instance per
class, that's why in my understanding of dependcy Injection it is not
working with it (correct me please if I'm wrong). And this singleton is
used to log in all methods of the class/object.

Surely I would be able to get the specializied Singleton instance with
doing some code like the following two examples:

Example 1 (As I already would be prefered solution for me if I use the
Logger only in a few of the methods and not in the majority of it):

class A {

   private static $LOG;

   private static function initLogger() {
  if (self::$LOG = null) {
  self::$LOG = LogAdapter::getLogger(self::class);
  }
   }

   public static function a() {
  self::initLogger();

  self::$LOG-debug();
  
  self::$LOG-error();
   }

   public function b() {
  self::initLogger();

  ...
  self::$LOG-error();
   }

   ...

}

or Example 2: (which is in my opinion really hard to read and to much to
write)

class A {

   public static function a() {
  LogAdapter::getLogger(self::class)-debug();
  
  LogAdapter::getLogger(self::class)-error();
   }

   public function b() {
  ...
  LogAdapter::getLogger(self::class)-error();
   }

   ...

}

With my solution of a static constructor it would look like this.

class A {

   private static $LOG;

   private static function __static() {
  self::$LOG = LogAdapter::getLogger(self::class);
   }

   public static function a() {
  self::$LOG-debug();
  
  self::$LOG-error();
   }

   public function b() {
  ...
  self::$LOG-error();
   }

   ...

}

On huge classes with 10 or more methods all using the LOG reference this
is in my opinion the cleanest and shortest solution.

I hope I could make the example more clear?! If you need more examples
please let me know.

Regards
-- 
DerOetzi

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

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

Hey Derick,

 IMO, because it's not obvious whether it is *all* empty, or *atleast
 one* empty. The same argument we had before, when we expanded isset() to
 be variadic. We had the same discussion then, resulting on keeping
 empty() as it is.

 One discussion 11 years ago:
 http://marc.info/?l=php-internalsm=109836951711930

 I can't find the discussion prior to that though.

 cheers,
 Derick

Thanks for the link. I wasn't aware this had come up in the past.

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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Patrick Schaaf wrote on 12/03/2015 18:40:


Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com 
mailto:rowan.coll...@gmail.com:


 Johannes Ott wrote on 12/03/2015 17:05:

 So doing a null check each time
 is a overhead of calculation which can be avoided with this static
 constructor pattern.

 Presumably the engine would need to perform some implicit 
equivalent of

 if ( ! self::$initialised ) on each call to decide if the static
 constructor needs to be called or not, so the overhead is not 
completely

 eliminated.

 Yes you are right but I think it can be done more efficiently 
inside the

 interpreter using some struct flags then have to parse each time inside
 a coded part in the application.

 Yes, point taken.

I don't think such a flag is neccessary at all. Any class. at the 
moment, comes from one or another file that is included / required. 
And all of the code in these files outside the class definition, is 
then immediately executed. The only thing neccessary would be to 
check, just before that execution begins, which of the new classes 
have such an initializer method, and then call that, before the 
execution of the file itself begins.




This was my initial interpretation, but Johannes has explained that that 
is not the intention of this proposal. Instead, it is intended to be 
called on first *use* of the class; a subtle difference, but given this 
code:


class A { public static $foo; private function __static() { echo 'A'; } }
class B { public static $foo; private function __static() { echo 'B'; } }
B::$foo = 1;
A::$foo = 2;

Running the magic at definition time will echo 'A' then 'B'; running it 
on first use will echo 'B' then 'A'.



Incidentally that is something that cannot be emulated with the 
autoloader-does-it approach, because the autoloader can only do that 
after the include/require is complete - i.e. code within the file will 
not yet see the class as initialized (in that approach).


For that scenario, the autoloader can immediately call 
$class_name::__static() or whatever. The only edge-case is when you try 
to also put loose code in your class definition files, but why would you 
need to?


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 20:34 schrieb Rowan Collins:
 Patrick Schaaf wrote on 12/03/2015 18:40:

 Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com
 mailto:rowan.coll...@gmail.com:
 
  Johannes Ott wrote on 12/03/2015 17:05:
 
  So doing a null check each time
  is a overhead of calculation which can be avoided with this static
  constructor pattern.
 
  Presumably the engine would need to perform some implicit
 equivalent of
  if ( ! self::$initialised ) on each call to decide if the static
  constructor needs to be called or not, so the overhead is not
 completely
  eliminated.
 
  Yes you are right but I think it can be done more efficiently
 inside the
  interpreter using some struct flags then have to parse each time
 inside
  a coded part in the application.
 
  Yes, point taken.

 I don't think such a flag is neccessary at all. Any class. at the
 moment, comes from one or another file that is included / required.
 And all of the code in these files outside the class definition, is
 then immediately executed. The only thing neccessary would be to
 check, just before that execution begins, which of the new classes
 have such an initializer method, and then call that, before the
 execution of the file itself begins.

 
 This was my initial interpretation, but Johannes has explained that that
 is not the intention of this proposal. Instead, it is intended to be
 called on first *use* of the class; a subtle difference, but given this
 code:
 

Correct! On that point I agree with Rowan, for the fact that there a lot
of of libraries and application in user-land which don't use autoload
function to include the classes when required, but include all classes
at the startup, but on different paths through the application only use
a few of them. Or in future the interpreter or a maybe application
server will have some optimization which loads the classes it may need
already in memory, but never use it then.

The static constructor pattern should avoid overhead in all of this
current and possible future cases.

Instead the static constructor should behave like the following user-code:

class A {
private static $bInitialized = false;

...

private static function init() {
   if (self::$bInitialized) {
   return;
   }

   ...
   self::$bInitialized = true;
}

public static function a() {
self::init();
...
}

public function b() {
self::init();
...
}

...
}


So we need the $bInitialized flag in the struct.

Another point already mentioned for the example where the static
constructor uses database connection or something there can be a lot of
unnecassary db-connections opened on creation time.

Regards,

-- 
DerOetzi

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

Re: [PHP-DEV] static constructor

[Patrick Schaaf]

Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com:

 Johannes Ott wrote on 12/03/2015 17:05:

 So doing a null check each time
 is a overhead of calculation which can be avoided with this static
 constructor pattern.

 Presumably the engine would need to perform some implicit equivalent of
 if ( ! self::$initialised ) on each call to decide if the static
 constructor needs to be called or not, so the overhead is not completely
 eliminated.

 Yes you are right but I think it can be done more efficiently inside the
 interpreter using some struct flags then have to parse each time inside
 a coded part in the application.

 Yes, point taken.

I don't think such a flag is neccessary at all. Any class. at the moment,
comes from one or another file that is included / required. And all of the
code in these files outside the class definition, is then immediately
executed. The only thing neccessary would be to check, just before that
execution begins, which of the new classes have such an initializer method,
and then call that, before the execution of the file itself begins.
Incidentally that is something that cannot be emulated with the
autoloader-does-it approach, because the autoloader can only do that after
the include/require is complete - i.e. code within the file will not yet
see the class as initialized (in that approach).

(I wrote at the moment above,  because the currently proposed anonymous
class thing would need extra thought when the anonymous class has such an
initializer method...)

best regards
  Patrick

Re: [PHP-DEV] static constructor

[Patrick Schaaf]

Am 12.03.2015 20:12 schrieb Dan Ackroyd dan...@basereality.com:

 Patrick Schaaf wrote:
  But that has proven, in the past, a fountain of joy wrt.
  placement, with variations needed for APC and opcache, and general
frustration
  all around.

 Is there a bug report for the problems? OPCache shouldn't have
 side-effects on the code.

The issues we had were never reproducible in any controlled way, so no bug
reports.
Back in that time there was also an inordinate amount of mixed autoloading
(being phased in) and lots of include/require spaghetti (being phased out).
I don't remember any details, just that I don't want to remember them.

best regards
  Patrick

Re: [PHP-DEV] static constructor

[Dan Ackroyd]

Patrick Schaaf wrote:
 But that has proven, in the past, a fountain of joy wrt.
 placement, with variations needed for APC and opcache, and general frustration
 all around.

Is there a bug report for the problems? OPCache shouldn't have
side-effects on the code.

cheers
Dan



On 12 March 2015 at 08:40, Patrick Schaaf p...@bof.de wrote:
 On Thursday 12 March 2015 00:10:15 Rowan Collins wrote:
 On 11/03/2015 23:21, Johannes Ott wrote:

  The purpose of this suggestion is to introduce a static constructor,
  which is called before the first call to class either static or
  non-static to initialize some static properties which are needed by the
  class.

 Can you give an example use case for when this would be useful? I'm
 struggling to think of one for which there isn't already an established
 coding pattern...

 It's useful everywhere you now have more than one method starting

 if (!static::$is_initialized) static::initialize_me();

 Some examples from our codebase:

 - a session wrapper class, hiding $_SESSION behind setter/getter methods,
 where the static class initialization determines which cookie to use,
 depending on some global feature flags, and which session backend to use,
 depending on current availability. (main purpose, apart from clean calling
 side code just using the setters/getters, is to get the lazy_write
 functionality Yasuo tried to introduce recently)

 - computation of some class properties from others, like doing an array_flip
 on one to get a reverse mapping.

 - definition of computed constants, in various places. Partly obsolete now
 that class constants support constant expressions, but needed as soon as these
 are not really constant.

 - setting up some class properties used by various methods, that should depend
 on some global feature flags (defined by the users of the class, usually
 toplevel scripts)

 - invariant checks on subclasses, in various places, where concrete subclasses
 set up some static properties of a configuration nature, and I want to make
 sure in the base class, as early as possible, that the values are consistent
 and make sense, avoiding checks spread all over the place in various methods.

 Of course, most of this could be done by code outside the class definition, in
 the same file. But that has proven, in the past, a fountain of joy wrt.
 placement, with variations needed for APC and opcache, and general frustration
 all around.

 best regards
   Patrick







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


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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 21:33 schrieb Rowan Collins:
 Johannes Ott wrote on 12/03/2015 19:45:
   All of the magic methods are doing like this.
 
 I thought you might say that, but the only thing remotely similar I can
 think of is a destructor, which gets called when an object goes out of
 scope; the others are all the implementation of, or instead of, some
 specific piece of code:
 __construct() runs every time for new Foo
 __get() and __set() runs every time for property access with - on an
 undefined property
 __call() and __callStatic() runs every time for method access on an
 undefined property
 
 The difference with this is that you never know which part of your code
 will actually trigger it, because it only runs some of the time.


I cannot see any difference because the trigger is defined really clear
for each of the functions

For Example Class Foo implements all of those functions the triggers
would be

__construct - triggered each time I write new Foo()

__destruct - triggered each time a instance loses his last reference
and is removed by garbage collection.

__get() and __set() -  triggered each time I try to access a property
of my foo instance which is not accessible (not defined or private) from
outside Foo writing $foo-notfromoutside

__call() - triggered each time I try to call a non-static method on a
instance of Foo which is not accessible from outside writing
$foo-notfromoutside()

__callStatic() - triggered each time I try to access static method of
the class which is not accessible from outside writing Foo::notfromoutside()

And finally the proposed new one

__static() - triggered on the first time I write either new Foo() or
Foo::eachStaticPublicOrProtectedMethodOrProperty()

I really don't see what __static() has more magic or unclear trigger
then each of the other so called magic methods?!

Do keep away any doubt, in my opinion none of the so called magic
methods have any kind of magic. They are just language patterns you
should understand how they work before you start to use them in your
code! So private static function __static() {...} is just another
pattern you have to understand before you use. If you don't understand
how it works you should not use. That is the same for all language
patterns and elements, for example: loops, conditions, scalar-operators,
etc.

And as I already told a static class constructor is a kind of well-known
standard function in mostly all modern OOP-languages. So professional
OOP-developer should be or become very fast familiar with this pattern.

 
 Okay thats a point I have to clearify I see, maybe my examples where to
 much shorten by me. In my examples I'm showing only the initialize parts
 of the classes, the initialized properties are used all over the class
 in static as well in non-static context.
 
 OK, so these are classes which share certain resources between all
 instances, represented by these static properties. In that case, would
 it be reasonable to say that the initialization of these properties
 needs to happen the first time an instance is created? If so, the
 if(self::$initialized) check needs to run only as often as
 __construct(), not every time any method is called.


If you look closer at my example you will see, that the property is not
just shared between instances (then the normal constructor Could be
indeed be the place to initialize), but it is shared although with
different static methods inside the class.

 If the static methods are public, and used for something other than
 managing instances (Factory / Singleton / etc), then are they really the
 responsibility of the same class? i.e. do you have a Utility class
 hiding in there pretending to be part of the instance/factory class?
 


See my example 2 for a Config Wrapper class:

abstract class Config {
private static $arIni;

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

//For example check whether all required fields are in the file
or throw Exception if not.
}

public static function getHostname() {
return self::$arIni['hostname'];
}

public static function getDBConnectionString() {
return ' self::$arIni['dbdriver'] . '://' .
self::$arIni['dbuser'] . '@' .self::$arIni['dbhost'] ...;
}

...
}

The Config class is in response for all config Parameters inside
config.ini and needs to read in this file before it can to it's work
correctly. No hiding of Factory/Singleton/instance in this.

And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary abstraction level for nothing in my opinion!

 For use case 1 the LogAdapter for example is a singleton instance per
 class, that's why in my understanding of dependcy Injection it is not
 working with it (correct me please if I'm wrong). And this singleton is
 used to log in all 

Re: [PHP-DEV] static constructor

[Christoph Becker]

Johannes Ott wrote:

 And i although see no DI or Singleton pattern to use here to get the
 same functionality, if you want to use like Config::getHostname() and
 not like Config::getInstance()-getHostname() which is really
 unnecessary abstraction level for nothing in my opinion!

It is possible, however, to add static wrapper methods to access the
singleton's methods, like

  public static function getHostname() {
  return self::getInstance()-_getHostname();
  }

 It is not only about the extra method-call but although the additional
 Null check inside this method call.
 
 Let's do some calculation for that: in average I have 5 calls of the
 logger per method the message is used 10 times during the programm.
 Now we already have 49 unnecessary method calls (with all needed to do
 for the interpreter like preparing stack, copying the returns etc.) and
 40 unnecassary null checks inside (as we agreed before that is not
 counted fully, because the evaluation of the flag will although take
 some time but can be more efficient inside the interpreter). Let's now
 think only about 10 such methods we are already at a count of 490
 unnecessary method calls. Maybe only slightly worse performance but it
 is a performance issue! And there is this very old performance rule: a
 lot of small performance issues can become quickly to a huge one.
 
 I have counted the calls in code of self::$LOG- inside one small
 private webproject of mine with less logging implemented yet. But there
 are already 128 calls. If you multiply by 10 you already have 1280 calls
 on runtime, I think that is a performance issue.

It seems to me that the logger example is not appropriate to show
performance penalties due to unnecessary method calls and null checks,
because the actual task of the logger (write to a file/database, or even
send an email) is easily much more demanding performance-wise.

Anyhow, in my humble opionion, there had been enough initial discussion
on this idea, and it would be reasonable to proceed with the actual RFC.
 See How To Create an RFC[1] and especially The Mysterious PHP RFC
Process and How You Can Change the Web[2]. :)

[1] https://wiki.php.net/rfc/howto
[2] https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5

[Pascal Martin, AFUP]

Le 26/02/2015 15:58, Anthony Ferrara a écrit :

I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.

Hi,

We were, at AFUP, +1 for the v0.3 of this RFC, and it seems we still are 
on the +1 side for this v0.5


Thanks for having re-vived this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/


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

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

[Dan Ackroyd]

On 12 March 2015 at 09:58, Thomas Punt tp...@hotmail.co.uk wrote:
 Hey PHP Internals,
 I'm not entirely sure why
 people are against it - and no one seems to want to debate it either.

I think these were covered in the discussion phase, but I will
reiterate the reasons I voted against it for clarity.

 The falsy semantics of empty() means that inlining its behaviour to exactly 
 match
 isset() isn't logical.

The problem isn't so much that the behaviour doesn't match some other
pattern in PHP; the problem is that the function doesn't do what its
name says it does.

if any arguments passed into empty() are considered falsy, then true
will be returned

i.e. it doesn't check whether the arguments are 'empty', it's checking
whether they are 'all set and not falsy'. Having a function do
something different to what it's name suggests will lead to it being
used incorrectly a lot of the time.

The other reason I voted no, is that I just don't think this adds
enough to the language to be implemented in core. For at least two of
the examples in the RFC the desired functionality could be implemented
in userland.

The size of the PHP core codebase is already unwieldy. I think any
suggested addition needs to have a clear advantage over being
implemented in userland

cheers
Dan

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

Re: [PHP-DEV] static constructor

[Rowan Collins]

Patrick Schaaf wrote on 12/03/2015 08:40:

On Thursday 12 March 2015 00:10:15 Rowan Collins wrote:

On 11/03/2015 23:21, Johannes Ott wrote:


The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are needed by the
class.

Can you give an example use case for when this would be useful? I'm
struggling to think of one for which there isn't already an established
coding pattern...

It's useful everywhere you now have more than one method starting

if (!static::$is_initialized) static::initialize_me();


I suspect that most places where this occurs, there are other ways to 
eliminate it than adding magic pre-initialisation. If a class has lots 
of static methods all depending on some state being initialised, maybe 
they just shouldn't be static - they should be instance members of a 
Singleton or Dependency Injected object. Or maybe they're accessing 
members directly which would be better hidden behind an accessor method 
which loads some data and caches its result.




Some examples from our codebase:

- a session wrapper class, hiding $_SESSION behind setter/getter methods,
where the static class initialization determines which cookie to use,
depending on some global feature flags, and which session backend to use,
depending on current availability. (main purpose, apart from clean calling
side code just using the setters/getters, is to get the lazy_write
functionality Yasuo tried to introduce recently)


This sounds like a job for a Singleton or Dependency-Injected object. 
The initialisation is a specific action with its own parameters (which 
you're currently grabbing from global configuration).




- computation of some class properties from others, like doing an array_flip
on one to get a reverse mapping.

- definition of computed constants, in various places. Partly obsolete now
that class constants support constant expressions, but needed as soon as these
are not really constant.


This is the only case that seems valid to me: enums and other types of 
computed constant, where the class is just there as a container.




- invariant checks on subclasses, in various places, where concrete subclasses
set up some static properties of a configuration nature, and I want to make
sure in the base class, as early as possible, that the values are consistent
and make sense, avoiding checks spread all over the place in various methods.


The question is, why is this whole hierarchy static? If these were 
instances not definitions, the initialisation is a well-defined event 
(the constructor), and you can check validity there.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] static constructor

[Johannes Ott]

Am 12.03.2015 um 12:16 schrieb Crypto Compress:
 Hello Johannes,
 
 class Foo {
 private static function __static() {
 throw new Exception(boom);
 }
 }
 
 while(true) {
 try {
 $foo = new Foo;
 } catch (Exception ex) {}
 }
 
 Would this code be valid?

Have to think about this issue, but on the first look I would say yes!

Because the meaning of the static constructor is to do some necassary
initialize for the class it should be able to throw an Exception if it
cannot do it's work correctly. For example if it needs to read some
configuration from a Database and is not able to connect.

For the caller I although would say, that the error inside the static
constructor should be catchable, for the simple fact that every Error
should be catchable for user-errorhandling.

What is your point of view for this? I'm open for discussion about this.

Regards
-- 
DerOetzi

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

Re: [PHP-DEV] static constructor

[Niklas Keller]

2015-03-12 12:33 GMT+01:00 Johannes Ott m...@deroetzi.de:

 Am 12.03.2015 um 12:16 schrieb Crypto Compress:
  Hello Johannes,
 
  class Foo {
  private static function __static() {
  throw new Exception(boom);
  }
  }
 
  while(true) {
  try {
  $foo = new Foo;
  } catch (Exception ex) {}
  }
 
  Would this code be valid?

 Have to think about this issue, but on the first look I would say yes!

 Because the meaning of the static constructor is to do some necassary
 initialize for the class it should be able to throw an Exception if it
 cannot do it's work correctly. For example if it needs to read some
 configuration from a Database and is not able to connect.


How would it behave for the second call? If the first initialize fails due
to some exception, should that static constructor be executed again?


 For the caller I although would say, that the error inside the static
 constructor should be catchable, for the simple fact that every Error
 should be catchable for user-errorhandling.

 What is your point of view for this? I'm open for discussion about this.

 Regards
 --
 DerOetzi

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


Regards, Niklas

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

[Dan Ackroyd]

On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:

 Can we please come down to a single RFC, with a single vote yes/no?
 It's easier to understand, easier to manage and has less possibility
 of gaming.


While I generally agree, in the case where there is a small detail
that needs to be addresses by a vote, I think having two votes in one
RFC is better than having two almost identical RFCs.

However the question that is being voted on needs to be setup properly
so that it does not prevent people from being able to vote on both
issues.

For example the group use RFC
(https://wiki.php.net/rfc/group_use_declarations) has a small detail
of whether there should be a trailing slash in the syntax, which did
not deserve a separate RFC imo.

Unfortunately, the vote options were:
- Yes - with a trailing \
- Yes - without a trailing \
- No

This meant it was impossible for people who wanted to vote no to the
general idea, to say what was their preferred choice of syntax. The
questions and voting choices should have been:

 Should Grouped Use Declarations be added to PHP 7
- Yes
- No

If added, should the syntax be with trailing \ or without.
- With a trailing \
- Without a trailing \

This would have allowed all voters to express their intent for both
parts of the question, without being forced to vote 'yes' if they want
a say in the exact syntax used.

cheers
Dan
Ack

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

Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

[Derick Rethans]

On Tue, 10 Mar 2015, Patrick ALLAERT wrote:

 2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com:
 
  Can we please come down to a single RFC, with a single vote yes/no?
  It's easier to understand, easier to manage and has less possibility
  of gaming.
 
 That is much more stricter than my thoughts but I can't agree more
 with you on all the points you mentioned.
 You even presented cases I had in mind, thanks for the verbosity :)

+1

 We should probably add this to https://wiki.php.net/rfc/voting which 
 should probably RFC'ed...

I think you just volunteerd ;-)

cheers,
Derick

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

Re: [PHP-DEV] Introduce DerOetzi

[Anthony Ferrara]

Welcome!!!

I'd love to hear more about your thesis if you can share!

Anthony

On Tue, Mar 10, 2015 at 6:56 AM, Johannes Ott m...@deroetzi.de wrote:
 Hi,

 sorry I did the wrong order, starting to discuss already without
 introducing me first:

 My name is Johannes Ott. I am 31 years old. I'm developing with PHP since
 2004, I have written my thesis about Testdriven development of a PHP-
 Framework with namespaces and 'typesafety' as implemented in PHP 5.3. I
 have developed some kind of autoboxing of scalar types and a new Master-
 Object like used in Java.

 Currently I'm working as a senior J(2)EE developer and as a Software
 Architect for a huge Oracle ADF project since 2 years now. But I'm still
 programming PHP for my hobby. I'm really interested in PHP7 new hashtable
 things and compiler issues.

 If you want more visit my Xing profile: https://www.xing.com/profile/
 Johannes_Ott5

 Regards

 DerOetzi

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


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

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

[Dan Ackroyd]

Voting no due to:

i) Having conversion rules be difference in userland to internal functions.

You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out again and
again. Why on earth should a boolean be convertible to int for some
functions but not others?

What will happen when someone writes  code that extends an internal
class and overrides one of the functions, is that the person who is
using that extended class will have to alter their code to use the
extended class in a different way to how they would use the built in
class directly.

For everyone who didn't pick this up in the RFC, it's hidden in the
large chunk of text:
Unlike user-land scalar type hints, internal functions will accept
nulls as valid scalars.


ii) The subtle BC breaks.

false - int   # No more conversion from bool
true - string # No more conversion from bool

btw You appear to have only tested this code against barebones
frameworks. These are often written far more cleanly than actual
applications so I don't think the report of 'very limited' BC breaks
is accurate.


iii) Having conversion work, except when they don't. People who want
weak type hints want weak type hints - they don't want code that
breaks unexpectedly.

function foo(int $bar){...}

foo(36/$value);
// works when $value = 1, 2, 3, 4 breaks when $value = 5

This is neither weak nor strict type - this is a horrible hybrid that
would only catch people out.

But finally, the fact that a significant part of the RFC is talking
about how the behaviour will need to be cleaned up in a future RFC,
but at the same time that some of the problems will be left for five
years show that this isn't a sensible RFC to vote for, even for the
people who just want weak types

cheers
Dan

.

On 11 March 2015 at 15:10, Zeev Suraski z...@zend.com wrote:
 The vote on the Coercive Scalar Type Hints is now open for voting.



 The latest version of the RFC includes changes discussed on internals@ last
 week:

 1.  Accept string-bool and int-bool conversions (false-bool is not
 supported)

 2.  Accept leading/trailing spaces in string-number conversions.



 wiki.php.net/rfc/coercive_sth

 wiki.php.net/rfc/coercive_sth#vote



 Thanks!



 Zeev

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