[PHP-DEV][RFC] Callable Types

[Marcio Almada]

Hello everyone,

We just completed the draft for the "Callable Types" RFC. This RFC has been
recently mentioned during other type related threads on this mailing list,
so it feels to be the right time to put the proposal in context:

The proposal is at https://wiki.php.net/rfc/callable-types

The W.I.P patch is available for testing through http://3v4l.org under the
RFC tab.

We count with your detailed feedback and insights. Let's have a nice,
respectful and
constructive conversation about the RFC and work on possible improvements!

Thanks
Nikita Nefedov
Márcio Almada

Re: [PHP-DEV] PHP 7.1 roadmap

[Davey Shafik]

I'd interested in co-RMing 7.1 if someone else wants to step up also?

- Davey

On Thu, Apr 21, 2016 at 2:47 AM, Julien Pauli  wrote:

> On Tue, Apr 12, 2016 at 10:20 PM, Scott Arciszewski 
> wrote:
> > On Tue, Apr 12, 2016 at 2:29 PM, Anatol Belski  wrote:
> >>
> >> Hi,
> >>
> >> Time goes by fast - no sooner 7.0 was unleashed on the world than 7.1
> >> bangs
> >> at the door.  I would like to bring a couple of points regarding this.
> >>
> >> There is enough time yet, but it would make full sense all the RFC
> authors
> >> targeting 7.1 to finalize the work and get the RFC voted. Or the RFCs,
> >> that
> >> have not been discussed yet - still some time is there to go through the
> >> full RFC process and get them ready for 7.1. It is anyway the right
> moment
> >> to intensify the discussions and work on 7.1 features and patches.
> >>
> >> It looks also like the right time to elect the 7.1 RMs. Please everyone
> >> interested to run for 7.1 RMs announce your candidacy to this thread. I
> >> would suggest to start the poll on this two weeks after this message,
> with
> >> the two weeks vote period.
> >>
> >> The prerelease cycle start could then happen already in June (or July,
> >> depends whether one wants to wait till 5.5 EOL). Anyway, having the new
> >> RMs
> >> team we can start to plan and proceed with the 7.1 prerelease cycle.
> >>
> >> Thanks
> >>
> >> Anatol
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> > Yikes, time really flies.
> >
> > The new ext/sodium is out, so I suppose it's high time to get that RFC
> ready
> > to be voted on.
>
>
> Time runs :-)
>
> Anyone for RMing 7.1 ?
> We obviously need someone to volunteer :-p
>
>
> Julien.Pauli
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Sara Golemon]

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov  wrote:
> I would like to present an RFC proposing support for native annotation.
>
I'm trying to imagine where the benefit of non-constant expressions comes in.

<>

Assuming we roll in php-ast at the same time (which is a big addition,
IMO, and deserves its own separate RFC), what are users meant to do
with this?  Even if there's a use-case here, one could accomplish the
same thing with:

<>

And manually running that string into php-ast if that's what the caller wanted.

Also, maybe I missed it, but I didn't see an answer to the question of
ambiguity between parsing the above as a straight string, versus
parsing it as a ZEND_AST_ZVAL.  I'm sure the answer is "If the AST
tree is just a ZVAL, then it's provided as the compile-time
expression, but what about something else like this:

<>

Logically, this is reducible to a single compile-time value, but it's
a complex expression, so would it be the value int(2)? Or
ZEND_AST_BINARY_OP(int(1), int(1))?

I just think that over-engineers what should be a simple annotation feature.

All that said, I love the proposal overall, and I can't wait to
propose builtin annotations like <<__Memoize>>, <<__Mock>>, and
similar.

-Sara

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

Re: [PHP-DEV] [RFC] PHP Attributes

[guilhermebla...@gmail.com]

Hi Dmitry,

As a previous suggester of metadata information built-in into PHP, and also
one of developers of the most used metadata library written in PHP, I
understand this feature implementation requires several design decisions
and also a good understanding of specific situations users may require.

While I am a strong supporter of a more robust solution, this is already a
good start.
A few things I'd like to ask for my own understanding and also suggestions
too:

1- I understand you took a minimalistic approach towards a "dumb"
implementation for attributes (when I mean "dumb", the idea here is towards
a non-OO approach). Can you explain your motivations towards this approach?

I see two distinct approaches of implementation for this feature. Both of
them have some common demands, like lazy initialization of metadata. Here
they are:

- Simplistic approach, which lets consumers of the feature do all the work
related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features that a
more robust implementation demands.

- Robust approach: language takes the burden of instantiating complex
structures, validating, assertion of valid keys, values, if this complex
structure is allowed to be instantiated in that given class, method, etc.

1- Your approach is basically defining an array. Could you explain your
line of thinking on why you didn't consider a syntax like the one below?

<["key" => "value"]>
class Foo {}

2- I see that you added support over functions, classes, constants and
properties. According to the RFC, getAttributes() was added over
ReflectionFunction. Is there a reason why support was not added to methods
(ReflectionMethod extends ReflectionFunctionAbstract, which was not
mentioned on RFC)? Any reason to not support it in function/method
parameters?

3- Did you put any thought on inheritance? What I mentioned in comment #1
is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support overrides,
inherit, etc?

4- I understand that a more robust attribute solution would be required to
achieve this, but one of the biggest advantages of AOP is the ability to
perform custom logic before, after or around... However, I don't know if
any kind of triggers came in your head or are planned as a future RFC.
Let me highlight one example: Every time a class, property or method is
called that is annotated as <>, I would like to issue an
E_USER_DEPRECATED warning. A trigger-like solution would be required. Did
this concept came to your mind?



Regards,

On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov  wrote:

>
>
> On 04/22/2016 02:16 AM, Dominic Grostate wrote:
>
>>
>> This is amazing.  It would actually allow us to implement our automated
>> assertions ourselves, as opposed to requiring it within the language.
>>
>> this was the idea - to give a good tool instead of implementing every
> possible use-case in the language.
>
> Could it also support references?
>>
>> <>
>> function foo($a) {
>>
>> }
>>
>> yes. "&$a" is a valid PHP expression.
>
> If you plan to use this, I would appreciate, if you to build the patched
> PHP and try it.
> The early we find problems the better feature we will get at the end.
>
> Thanks. Dmitry.
>
>
> On 21 Apr 2016 10:13 p.m., "Dmitry Stogov"  dmi...@zend.com>> wrote:
>>
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native
>> annotation.
>>
>> The naming, syntax and behavior are mostly influenced by HHVM
>> Hack, but not exactly the same.
>>
>> The most interesting difference is an ability to use arbitrary PHP
>> expressions as attribute values.
>>
>> These expressions are not evaluated, but stored as Abstract Syntax
>> Trees, and later may be accessed (node by node) in PHP extensions,
>> preprocessors and PHP scripts their selves. I think this ability
>> may be useful for "Design By Contract", other formal verification
>> systems, Aspect Oriented Programming, etc
>>
>>
>> https://wiki.php.net/rfc/attributes
>>
>>
>> Note that this approach is going to be native, in contrast to
>> doc-comment approach that uses not well defined syntax, and even
>> not parsed by PHP itself.
>>
>>
>> Additional ideas, endorsement and criticism are welcome.
>>
>>
>> Thanks. Dmitry.
>>
>>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:16 AM, Dominic Grostate wrote:


This is amazing.  It would actually allow us to implement our 
automated assertions ourselves, as opposed to requiring it within the 
language.


this was the idea - to give a good tool instead of implementing every 
possible use-case in the language.



Could it also support references?

<>
function foo($a) {

}


yes. "&$a" is a valid PHP expression.

If you plan to use this, I would appreciate, if you to build the patched 
PHP and try it.

The early we find problems the better feature we will get at the end.

Thanks. Dmitry.

On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" > wrote:


Hi,


I would like to present an RFC proposing support for native
annotation.

The naming, syntax and behavior are mostly influenced by HHVM
Hack, but not exactly the same.

The most interesting difference is an ability to use arbitrary PHP
expressions as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax
Trees, and later may be accessed (node by node) in PHP extensions,
preprocessors and PHP scripts their selves. I think this ability
may be useful for "Design By Contract", other formal verification
systems, Aspect Oriented Programming, etc


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


Note that this approach is going to be native, in contrast to
doc-comment approach that uses not well defined syntax, and even
not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:09 AM, Colin O'Dell wrote:

> A more robust alternative would be something along the same lines that
> Doctrine uses: Make annotations actual classes.

Just spitballing here - what if both approaches were supported, but 
class-based annotations were prefixed with a special character 
(perhaps "@") to differentiate them?  For example:


<>
<<@ORM\Entity(table => "foo")>>
class Foo {
// ...
}

namespace ORM;
class Entity implements \Attribute {
// ...
}

$r = new ReflectionClass('ORM\Entity');
var_dump($r->getAttributes());

-

array(2) {
["ArbitraryAnnotation"]=>
string(11) "Hello world"
["ORM\Entity"] =>
object(ORM\Entity)#1 (0) { ... }
}

-

Again, I'm not necessarily advocating this - just throwing the idea 
out there for discussion.


Current proposal doen't support this, but this may be a good idea.
1) Attribute names might be not just strings, but also namespace qualified.
2) They may be optionally prefexed by some special character.

To create or not to create attribute objects is the question for next 
layer, but the base layer should provide necessary information.


Thanks. Dmitry.




Regards,

Colin

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:02 AM, Ryan Pallas wrote:



On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov > wrote:



About expressions, isn't there an ambigoutiy? <> is a
"plain" name, value based attribute. But it could also be an
ast\node of a function call to "test(1)"

even in AST scalars are scalars.
so <> would return: ast\node "+" with two children
int(1) and int(2).

I am wondering if they shouldn't get their own start/end signs
to clear that up, <<> vs <>.


no need for extra complication.

Since the encapsulated meta-data is an AST, and as you say any valid 
php expression will be valid here, what about bit shifting?


<> BAR)>>
This works because attributes are implemented as native part of 
context-free PHP grammar.


Are there concerns about finding the T_SR token, which is also the end 
annotation symbol? I've not done any work in the parser, so excuse me 
if that is an insanely stupid question :)

Not a problem. Better to get false alarm then miss a real one :)


Otherwise, I think this RFC looks great, and appreciate your work on 
this :)



Thanks. Dmitry.


Ryan

Re: [PHP-DEV] [RFC] PHP Attributes

[Dominic Grostate]

This is amazing.  It would actually allow us to implement our automated
assertions ourselves, as opposed to requiring it within the language.

Could it also support references?

<>
function foo($a) {

}
On 21 Apr 2016 10:13 p.m., "Dmitry Stogov"  wrote:

> Hi,
>
>
> I would like to present an RFC proposing support for native annotation.
>
> The naming, syntax and behavior are mostly influenced by HHVM Hack, but
> not exactly the same.
>
> The most interesting difference is an ability to use arbitrary PHP
> expressions as attribute values.
>
> These expressions are not evaluated, but stored as Abstract Syntax Trees,
> and later may be accessed (node by node) in PHP extensions, preprocessors
> and PHP scripts their selves. I think this ability may be useful for
> "Design By Contract", other formal verification systems, Aspect Oriented
> Programming, etc
>
>
> https://wiki.php.net/rfc/attributes
>
>
> Note that this approach is going to be native, in contrast to doc-comment
> approach that uses not well defined syntax, and even not parsed by PHP
> itself.
>
>
> Additional ideas, endorsement and criticism are welcome.
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Colin O'Dell]

>
> $r = new ReflectionClass('ORM\Entity');
> var_dump($r->getAttributes());
>

Oops, that should've been:

$r = new ReflectionClass('Foo');
var_dump($r->getAttributes());

Colin

Re: [PHP-DEV] [RFC] PHP Attributes

[Colin O'Dell]

> A more robust alternative would be something along the same lines that
> Doctrine uses: Make annotations actual classes.

Just spitballing here - what if both approaches were supported, but
class-based annotations were prefixed with a special character (perhaps
"@") to differentiate them?  For example:

<>
<<@ORM\Entity(table => "foo")>>
class Foo {
// ...
}

namespace ORM;
class Entity implements \Attribute {
// ...
}

$r = new ReflectionClass('ORM\Entity');
var_dump($r->getAttributes());

-

array(2) {
["ArbitraryAnnotation"]=>
string(11) "Hello world"
["ORM\Entity"] =>
object(ORM\Entity)#1 (0) { ... }
}

-

Again, I'm not necessarily advocating this - just throwing the idea out
there for discussion.

Regards,

Colin

Re: [PHP-DEV] [RFC] PHP Attributes

[Ryan Pallas]

On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov  wrote:
>
>
>> About expressions, isn't there an ambigoutiy? <> is a "plain"
>> name, value based attribute. But it could also be an ast\node of a function
>> call to "test(1)"
>>
> even in AST scalars are scalars.
> so <> would return: ast\node "+" with two children int(1) and
> int(2).
>
> I am wondering if they shouldn't get their own start/end signs to clear
>> that up, <<> vs <>.
>>
>
> no need for extra complication.
>
> Since the encapsulated meta-data is an AST, and as you say any valid php
expression will be valid here, what about bit shifting?

<> BAR)>>

Are there concerns about finding the T_SR token, which is also the end
annotation symbol? I've not done any work in the parser, so excuse me if
that is an insanely stupid question :)

Otherwise, I think this RFC looks great, and appreciate your work on this :)

Ryan

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 01:03 AM, Benjamin Eberlei wrote:


On Thu, Apr 21, 2016 at 11:13 PM, Dmitry Stogov > wrote:


Hi,


I would like to present an RFC proposing support for native
annotation.

The naming, syntax and behavior are mostly influenced by HHVM
Hack, but not exactly the same.

The most interesting difference is an ability to use arbitrary PHP
expressions as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax
Trees, and later may be accessed (node by node) in PHP extensions,
preprocessors and PHP scripts their selves. I think this ability
may be useful for "Design By Contract", other formal verification
systems, Aspect Oriented Programming, etc


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


Note that this approach is going to be native, in contrast to
doc-comment approach that uses not well defined syntax, and even
not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


I love it!

Syntax is good, and i like that it just returns plain arrays. 
Everything else (more formal) can be added on top by Doctrine 
Annotations for example.


thanks for support :)


About expressions, isn't there an ambigoutiy? <> is a "plain" 
name, value based attribute. But it could also be an ast\node of a 
function call to "test(1)"

even in AST scalars are scalars.
so <> would return: ast\node "+" with two children int(1) and 
int(2).


I am wondering if they shouldn't get their own start/end signs to 
clear that up, <<> vs <>.


no need for extra complication.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 12:52 AM, Larry Garfield wrote:

On 4/21/16 4:13 PM, Dmitry Stogov wrote:

Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, 
but not exactly the same.


The most interesting difference is an ability to use arbitrary PHP 
expressions as attribute values.


These expressions are not evaluated, but stored as Abstract Syntax 
Trees, and later may be accessed (node by node) in PHP extensions, 
preprocessors and PHP scripts their selves. I think this ability may 
be useful for "Design By Contract", other formal verification 
systems, Aspect Oriented Programming, etc



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


Note that this approach is going to be native, in contrast to 
doc-comment approach that uses not well defined syntax, and even not 
parsed by PHP itself.



Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.


Thanks, Dmitry!  In concept I am in favor of syntax-native 
annotations, although I have some concerns with the specifics of the 
proposal.  Thoughts in no particular order:


First, for the getAttributes() reflection method, please oh please 
don't return array-or-false.  That's horrible.  Just return an empty 
array if there aren't any, as that makes getAttributes() entirely type 
safe and saves all callers from a mandatory if-check.  (See 
http://www.garfieldtech.com/blog/empty-return-values for more 
information.)

Makes sense. I may change this.


The reflection section further indicates that the type of the result 
is variable, which means I cannot know in advance if I'm going to get 
back a scalar or an array.  If we go with this free-form approach, I'd 
honestly prefer to always get back an array, even for single value, so 
that I can always know the type I'm dealing with. (Since I cannot 
enforce a given attribute to be single-value.)


I'm not sure yet. both decisions may make sense. If I expect just a 
single value, I'll have to check the number of elements (or just ignore 
values above the first).


For the expression example:

<  0)>>
function  foo($a,  $b)  {
}


It is not at all clear to me what scope the annotation's $a and $b 
exist in.  Are the they same $a and $b as in the function signature? 
If so, what happens if I reflect the function before ever calling it?
This is just an AST. It may contain any valid PHP expression syntax, but 
variable, functions and constants don't have to be valid.



How can I evaluate test?
I hope this functionality will be provided by php-ast extension. 
Currently, it is not a problem to reconstruct PHP source from AST and 
then use regular eval().

In general, we may find a more efficient way.

Or are they inherited from the global scope at the time of 
declaration?  (That scares me a great deal.)  I don't know what to 
make of that at all.
AST is going to be mainly used by extension and pre-processors (like AOT 
and DBC), but in general, they also may be used directly in scripts.


<  0)>>
function  foo($a,  $b)  {
ast_eval(RefelectionFunction(__FUNCTION__)->getAttributes()["test"]);
}


DB
In the "Attribute syntax" section, the text says the tokens are the 
left and right double-angle character, as used for quotations in some 
European languages.  The rest of the text says it's two left/right 
carrot characters, as seen above the comma and period on US 
keyboards.  I'm assuming the former is just a typo/auto-correct bug.


yeah, computers think they are too smart :)


If I read correctly, the following two would be semantically identical:

<>
function foo() {}

<>
<>
function foo() {}


right


Is there a reason you chose the name "attribute" rather than 
"annotations", which seems at least in PHP to be the more common term 
for this type of declaration?


I took the name from HHVM. Personally, I don't care about naming at all.



It appears that the annotations themselves are entirely free-form.
no. they are parsed according to PHP expression syntax rules. syntax 
mistakes in attributes are going to be caught at compile time.


At the risk of expanding the typing debate, this concerns me as then 
all we're adding is a new way to parse undocumented, undefined 
anonymous structs.  How can I say what annotations mean what for my 
ORM, or routing system, or whatever?  We're back to, essentially, 
out-of-band documentation of big anonymous structs (aka associative 
arrays).


A more robust alternative would be something along the same lines that 
Doctrine uses: Make annotations actual classes.  To wit:



<>
<>
<>
function foo($a, $b) { }

Where AThing, AnotherThing, and MoreThing are defined classes, and 
subject to namespaces and use statements.  Then what gets returned 
from getAttributes() is an array consisting of an instance of AThing, 
an instance of AnotherThing, and an instance of MoreThing. In this 
example we'd just 

Re: [PHP-DEV] [RFC:generics]

[Larry Garfield]

On 4/21/16 10:43 AM, Rowan Collins wrote:

guilhermebla...@gmail.com wrote on 21/04/2016 16:25:
I understand others mentioned we could create a new interface that 
wraps the other two interfaces, but that still doesn't solve the 
problem where I want to extend a class AND also implement a specific 
interface.


I covered this case in my previous mail: you can create an abstract 
class that extends a concrete class and adds an interface to it, and 
the extra methods are implicitly added as abstract for descendants to 
implement:


Creating a one off class or interface to handle intersection cases works 
iff you control all creation points for all objects that you may 
encounter.  That is rarely the case when dealing with 3rd party 
libraries, as is now typical.


--
--Larry Garfield


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

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

[Dan Ackroyd]

On 20 April 2016 at 23:16, Patrick ALLAERT  wrote:

> It's also perfectly possible to make all those Exceptions implement a
> "MatchingFailedException" interface (even empty).

Apologies for continuing the conversation, even after the RFC is
incredibly likely to pass, but; I don't understand that argument at
all, and think I disagree with the philosophy behind it.

If it was followed, it would mean that exception classes would need to
be aware of how they are being used. When exception classes are
defined in a library, and the exceptions are being caught in an
applicaton, wouldn't adding applicaton specific interfaces to the
libaries exception classes just violate the separation between the
two? It doesn't seem to be good practice.

It would also lead to multiple interfaces being added to each
exception class. e.g. if in the application we had these catches in
different places in the application:


try {
   return foo();
} catch (ResourceNotFoundException $e) {
   return FALSE;
} catch (ParamNotConvertedException $e) {
   return FALSE;
}

try {
   return bar();
} catch (ResourceNotFoundException $e) {
   return FALSE;
}
catch (AccessDeniedHttpException $e) {
   return FALSE;
}

try {
   return quux();
} catch (ResourceNotFoundException $e) {
   return FALSE;
} catch (MethodNotAllowedException $e) {
   return FALSE;
}

Where we specifically want to catch ResourceNotFoundException and one
other exception. If we followed your advice and added a specific
interface to the exceptions for each of the separate combinations, so
that we could catch just the interface we would end up with this:

class ResourceNotFoundException extends \Exception implements
FooExInterface, BarExInterface, QuuxExInterface {}

i.e. having to add one interface per usage. That doesn't seem that
great eitherand again is altering a class based on how it's going
to be used.

> It encourages people to replace any kind of condition with an exception,
> leading to less readable code and incomplete API.

I don't think this is the right attitude to have when designing a
progrmming language.

Any feature that enables developers to write code that covers edge
cases in their application is by it's very nature going to be possibly
to use in a way most people consider inappropriate.

It's much more productive to focus on making code/features that are
useful when used sensibly. Worrying that people might use it in a way
that you wouldn't recommend using it, is fundamentally the wrong
problem to try to address when designing a language.

I think that's true in general but particularly true in a language
like PHP where one application might be programmed in a very different
way to another application. What would be useful and appropriate for
one of them would be could considered a horrendous hack* in another
application.

If we are limiting ourselves to adding features that are correct and
appropriate to use in all applications, that is limiting ourselves to
a subset of the features that people would want to have to cover all
of their use-cases.

cheers
Dan
Ack

* For example, a lot of people strongly dislike annotations. A
significant number of people use annotations in their applications.
Neither groups is 'right' or 'wrong', but it would be wrong for the
people who don't like annotations to say that annotations should never
be used.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Benjamin Eberlei]

On Thu, Apr 21, 2016 at 11:52 PM, Larry Garfield 
wrote:

> On 4/21/16 4:13 PM, Dmitry Stogov wrote:
>
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native annotation.
>>
>> The naming, syntax and behavior are mostly influenced by HHVM Hack, but
>> not exactly the same.
>>
>> The most interesting difference is an ability to use arbitrary PHP
>> expressions as attribute values.
>>
>> These expressions are not evaluated, but stored as Abstract Syntax Trees,
>> and later may be accessed (node by node) in PHP extensions, preprocessors
>> and PHP scripts their selves. I think this ability may be useful for
>> "Design By Contract", other formal verification systems, Aspect Oriented
>> Programming, etc
>>
>>
>> https://wiki.php.net/rfc/attributes
>>
>>
>> Note that this approach is going to be native, in contrast to doc-comment
>> approach that uses not well defined syntax, and even not parsed by PHP
>> itself.
>>
>>
>> Additional ideas, endorsement and criticism are welcome.
>>
>>
>> Thanks. Dmitry.
>>
>
> Thanks, Dmitry!  In concept I am in favor of syntax-native annotations,
> although I have some concerns with the specifics of the proposal.  Thoughts
> in no particular order:
>
> First, for the getAttributes() reflection method, please oh please don't
> return array-or-false.  That's horrible.  Just return an empty array if
> there aren't any, as that makes getAttributes() entirely type safe and
> saves all callers from a mandatory if-check.  (See
> http://www.garfieldtech.com/blog/empty-return-values for more
> information.)
>
> The reflection section further indicates that the type of the result is
> variable, which means I cannot know in advance if I'm going to get back a
> scalar or an array.  If we go with this free-form approach, I'd honestly
> prefer to always get back an array, even for single value, so that I can
> always know the type I'm dealing with. (Since I cannot enforce a given
> attribute to be single-value.)
>
> For the expression example:
>
> <  0)>>
> function  foo($a,  $b)  {
> }
>
>
> It is not at all clear to me what scope the annotation's $a and $b exist
> in.  Are the they same $a and $b as in the function signature? If so, what
> happens if I reflect the function before ever calling it?  How can I
> evaluate test?  Or are they inherited from the global scope at the time of
> declaration?  (That scares me a great deal.)  I don't know what to make of
> that at all.
>

They don't exist in any scope. You get an AST of this expression, what you
do with it is entirely your choosing and you can set the scope/context
yourself.

>
> In the "Attribute syntax" section, the text says the tokens are the left
> and right double-angle character, as used for quotations in some European
> languages.  The rest of the text says it's two left/right carrot
> characters, as seen above the comma and period on US keyboards.  I'm
> assuming the former is just a typo/auto-correct bug.
>
> If I read correctly, the following two would be semantically identical:
>
> <>
> function foo() {}
>
> <>
> <>
> function foo() {}
>
> Is there a reason you chose the name "attribute" rather than
> "annotations", which seems at least in PHP to be the more common term for
> this type of declaration?
>
> It appears that the annotations themselves are entirely free-form. At the
> risk of expanding the typing debate, this concerns me as then all we're
> adding is a new way to parse undocumented, undefined anonymous structs.
> How can I say what annotations mean what for my ORM, or routing system, or
> whatever?  We're back to, essentially, out-of-band documentation of big
> anonymous structs (aka associative arrays).
>
> A more robust alternative would be something along the same lines that
> Doctrine uses: Make annotations actual classes.  To wit:
>
>
> <>
> <>
> <>
> function foo($a, $b) { }


> Where AThing, AnotherThing, and MoreThing are defined classes, and subject
> to namespaces and use statements.  Then what gets returned from
> getAttributes() is an array consisting of an instance of AThing, an
> instance of AnotherThing, and an instance of MoreThing. In this example
> we'd just call their constructors with the listed values and let them do as
> they will.  Doctrine uses named properties in the annotation that maps to
> properties on the object, which is even more flexible and self-documenting
> although I don't know how feasible that is without opening up the named
> properties can of worms globally.
>

I like that its just arrays, PHP is not exclusively OOP, so making this an
OOP feature doesn't make sense to me.

A library like Doctrine can always add the meaning on top, for example
checking:

<>
class User
{
}

Again resolving this against namespaces for example inside Doctrine
Annotations itself, like its done right now.


>
> Either way, the advantage then is that I know what 

Re: [PHP-DEV] [RFC] PHP Attributes

[Larry Garfield]

On 4/21/16 4:13 PM, Dmitry Stogov wrote:

Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and later may 
be accessed (node by node) in PHP extensions, preprocessors and PHP scripts their selves. 
I think this ability may be useful for "Design By Contract", other formal 
verification systems, Aspect Oriented Programming, etc


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


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.


Thanks, Dmitry!  In concept I am in favor of syntax-native annotations, 
although I have some concerns with the specifics of the proposal.  
Thoughts in no particular order:


First, for the getAttributes() reflection method, please oh please don't 
return array-or-false.  That's horrible.  Just return an empty array if 
there aren't any, as that makes getAttributes() entirely type safe and 
saves all callers from a mandatory if-check.  (See 
http://www.garfieldtech.com/blog/empty-return-values for more information.)


The reflection section further indicates that the type of the result is 
variable, which means I cannot know in advance if I'm going to get back 
a scalar or an array.  If we go with this free-form approach, I'd 
honestly prefer to always get back an array, even for single value, so 
that I can always know the type I'm dealing with. (Since I cannot 
enforce a given attribute to be single-value.)


For the expression example:

<  0)>>
function  foo($a,  $b)  {
}


It is not at all clear to me what scope the annotation's $a and $b exist 
in.  Are the they same $a and $b as in the function signature? If so, 
what happens if I reflect the function before ever calling it?  How can 
I evaluate test?  Or are they inherited from the global scope at the 
time of declaration?  (That scares me a great deal.)  I don't know what 
to make of that at all.


In the "Attribute syntax" section, the text says the tokens are the left 
and right double-angle character, as used for quotations in some 
European languages.  The rest of the text says it's two left/right 
carrot characters, as seen above the comma and period on US keyboards.  
I'm assuming the former is just a typo/auto-correct bug.


If I read correctly, the following two would be semantically identical:

<>
function foo() {}

<>
<>
function foo() {}

Is there a reason you chose the name "attribute" rather than 
"annotations", which seems at least in PHP to be the more common term 
for this type of declaration?


It appears that the annotations themselves are entirely free-form. At 
the risk of expanding the typing debate, this concerns me as then all 
we're adding is a new way to parse undocumented, undefined anonymous 
structs.  How can I say what annotations mean what for my ORM, or 
routing system, or whatever?  We're back to, essentially, out-of-band 
documentation of big anonymous structs (aka associative arrays).


A more robust alternative would be something along the same lines that 
Doctrine uses: Make annotations actual classes.  To wit:



<>
<>
<>
function foo($a, $b) { }

Where AThing, AnotherThing, and MoreThing are defined classes, and 
subject to namespaces and use statements.  Then what gets returned from 
getAttributes() is an array consisting of an instance of AThing, an 
instance of AnotherThing, and an instance of MoreThing. In this example 
we'd just call their constructors with the listed values and let them do 
as they will.  Doctrine uses named properties in the annotation that 
maps to properties on the object, which is even more flexible and 
self-documenting although I don't know how feasible that is without 
opening up the named properties can of worms globally.


Either way, the advantage then is that I know what annotations are 
available, and the class itself serves as documentation for what it is, 
what it does, and what its options are.  It also helps address 
collisions if two different libraries both want to use the same keyword; 
we already have a class name resolution mechanism that works and 
everyone is familiar with.


One concern is that not all classes necessarily make sense as an 
annotation; perhaps only classes with a certain interface can be used.  
Actually (thinking aloud here), that would be a possible solution to the 
named property issue.  To wit:


< 'a', b => 'b')>>
foo() {}

class AThing implements Attribute {
  public static function attributeCreate(array $params) {
return new static($param['a'], $param['b']);
  }
}

$r  

Re: [PHP-DEV] [RFC] Nullable Types

[Thomas Bley]

> Note that the same /would/ be possible with union types if given precedence:
> 
> function fn(): int|false {}

false is currently not supported in the union_types rfc.

Regards
Thomas


Fleshgrinder wrote on 21.04.2016 21:33:

> On 4/21/2016 6:33 PM, Thomas Bley wrote:
>> Hello Tom,
>> 
>> with default return value I mean to return a certain value if nothing else is
>> returned (similar to method parameters with a default value).
>> 
>> example 1:
>> 
>> declare(strict_types=0);
>> 
>> function my_strpos(string $haystack, string $needle): int = false {
>>   return 42; // return 42
>>   return false; // return false
>>   return true; // return 1
>>   return; // return false
>> }
>> 
>> example 2:
>> 
>> declare(strict_types=1);
>> 
>> function my_strpos(string $haystack, string $needle): int = false {
>>   return 42; // return 42
>>   return false; // return false
>>   return true; // fatal error
>>   return; // return false
>> }
>> 
> 
> I definitely do not like the equal sign in there because it goes against
> all my mathematical knowledge; an int is false?!?
> 
> Note that the same /would/ be possible with union types if given precedence:
> 
> function fn(): int|false {}
> 
> That being said, it is way too magic! A return without an argument is
> *void* and has to result in a `TypeError`. Really, start to think about
> the types as /checked annotations/ ...
> 
> /**
> * @return int|false
> */
> function fn() {}
> 
> function fn(): int|false {}
> 
> ... are equivalent and the former does not suddenly return *false* on
> its own and hell it shouldn't.
> 
> -- 
> Richard "Fleshgrinder" Fussenegger
> 
> 


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

Re: [PHP-DEV] [RFC:generics]

[Dennis Birkholz]

Hi all,

Am 20.04.2016 um 16:44 schrieb guilhermebla...@gmail.com:
> If I want to hire/move a person to a department that is registered in the
> system, but is not a 3rd party company person, how would you achieve that
> considering the following class structure?
> 
> class Person {}
> class Employee extends Person {}
> class AssociateEmployee extends Employee {}
> class Manager extends Employee {}
> 
> Considering your function:
> 
> function assignToDepartment(T $person) : bool;
> 
> Generic type "T" in the function prototype needs to accept Person (new
> hire), Employee and Manager (transfer), but not AssociateEmployee.
> Considering upper bounds support only, your best bet is "T extends Person",
> but that would accept AssociateEmployee to be provided, which contradicts
> the business rule. Accepting anything lower in the hierarchy prevents new
> hires.
> That's when lower bounds comes into play. If you define as "T super Manager",
> all Person, Employee and Manager gets accepted, but not the
> AssociatedEmployee, matching properly the business rule.

I have to strongly disagree with the last sentence here: "T super
Manager" only fulfills your business rule by accident. If you add a
"TeamLeader extends Employee" class, your complete example falls apart
and shows that it is a very bad idea to introduce a "T super X"
requirement. You really want "T implements Person except
AssociateEmployee" so that you can use them like you would use bitmasks.
I think that fundamentally contradicts how interfaces and inheritance
work. The type in the generic should specify which contract (Base
class/interface) you require at least inside the generic class/function.
Everything else is really strange to me. What about interfaces? If
Manager or Employee implement Serializable, will all other classes that
implement Serializable also be allowed here? Please let's not implement
"T super X" kind of generics for use cases that really need something
different.

Thanks,
Dennis

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

[PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and 
later may be accessed (node by node) in PHP extensions, preprocessors and PHP 
scripts their selves. I think this ability may be useful for "Design By 
Contract", other formal verification systems, Aspect Oriented Programming, etc


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


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] Quick sanity check ...

[Lester Caine]

On 21/04/16 20:11, Fleshgrinder wrote:
> On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
>> No of course not. The specific instance of error you had *this time* may
>> be solved. The problem won't be. You still have to deal with:
>> - How this object is initialized? How you ensure it *is* initialized and
>> that initialization is correct (0 is perfectly valid int)?
>> - How this object is unserialized and what if unserialized data has
>> non-integer or 0 or __wakeup has a bug?
>> - What if some code just writes 0 into $olderThan - you declared it as
>> public so anybody could mess with it?
>> - What if some code mixes signed and unsigned and you get negative
>> number instead of positive?
>> - What if this code runs on 32-bit but receives 64-bit value and
>> truncates it?
>>
>> And so on, and so forth, I probably missed more possibilities than I
>> mentioned. Declaring a type does not magically free one from correct
>> design and testing, and typed programs have bugs as much as non-typed
>> ones (maybe slightly different ones). Actually, one of the harms relying
>> on it would be the same problem safe_mode had - it's full of holes, it's
>> not safe and it creates wrong expectations. If you just write "int" and
>> expect your problems to magically go away - you're in for big and bad
>> surprises.

Add string handling to that. It's all very well knowing that the
variable is a string rather than an integer, but the length ten becomes
an important element of the validation.

> While I agree with Stanislav and the others that a stricter type system
> would not have prevented the bug. However, a stricter type system helps
> to limit the amount of tests one has to perform and that is often a good
> thing. That does not mean that dynamic type systems are shit. Actually
> the opposite is the case, it is the same situation with paradigms.
> 
> What I love about PHP is that we have a lot under one hood:
> multi-paradigm as well as loose and strict types. This allows one to
> choose the best tool for the current job.

One problem I'm struggling with is just when enabling 'strict types' is
the best tool as with the other type elements that have crept in. Is it
easier to handle the validation in a generic way and check for the fine
detail which the crude type checks simply miss.

> Relying on your language for a bit of safety as asked of it cannot be
> compared to `safe_mode` where magic happens in the background. When one
> declares and `int` than it should be an `int`. Of course that also means
> that one should know what an `int` is and how to validate it according
> to the current business rules.

While some of my client systems are now 64 bit, many of the windows
based machines HAVE to be configured as 32 bit simply to maintain access
to the hardware. So 64 bit SEQUENCE numbers need to be transparent on 32
bit builds where an 'int' may simply truncate the number?

> That being said, isn't Lester's goal to validate scalar strings all the
> time anyways? I mean, at least `mysqlnd` transforms all data from the DB
> automatically to the proper scalar types for optimal performance in your
> program. But if one keeps scalar strings everywhere and leaves proper
> type coercion to PHP, I mean, why not. It is definitely doable and
> strict types are definitely not necessary if done properly.

I don't enable mysqlnd if I can help it. I don't use mysql, so my data
handling is via ADOdb so my base target is
http://hg.lsces.org.uk/hg/Bitweaver%20Mirror/externals/adodb/file/6ca8e39bf7f5/drivers/adodb-firebird.inc.php
and if this type checking sugar has any place in there?

> The big difference I see is that Lester is working on his code for
> himself (or for a customer) and does not have to design APIs for
> hundreds of other developers. PHP is used in the way it was initially
> designed, as a glue language. I repeat myself but I cannot see the need
> for strict types here.

Bitweaver started off as a port of tikiwiki. It's user base has waned a
little, but while tikiwiki lost access to use firebird and some other
databases, we maintained that in bitweaver, and while you can use PDO if
you insist, ADOdb maintains a level of cross database working that is
STILL far superior to the abstractions that are currently playing catchup.

> If you are developing APIs that are going to be (ab)used by hundreds of
> other developers in ways you would never have foreseen things change.
> One wants to ensure that the API is as self-explanatory as possible and
> as easy to use as possible. This includes (to get back to one of your
> examples) that objects that should not be serialized are not
> serializable (`private function __sleep()`) and not deserializable
> (`private function __wakeup()`) nor cloenable if necessary. This
> includes self-explanatory required types, sane default values, and
> appropriate visibility of things.
> 
> PhpDoc is the classical tool for us here and Stanislav wrote in another
> thread that this is the tool of 

Re: [PHP-DEV] Quick sanity check ...

[Larry Garfield]

On 4/21/16 2:11 PM, Fleshgrinder wrote:


What I love about PHP is that we have a lot under one hood:
multi-paradigm as well as loose and strict types. This allows one to
choose the best tool for the current job.


^^ That thing.  PHP is a very eclectic language.  That's a good thing.  
Does that mean there's a lot to know?  To an extent, yes. But frankly, I 
still find needle/haystack more confusing than any of the new features 
from the "PHP 6" era (PHP 5.3-5.6) or PHP 7.  And things that Zeev is 
(rightly) encouraging like async primitives would likely be far more 
confusing for current PHP developers than being able to say "this 
parameter has to implement both of these interfaces".


No one is arguing that typing is a replacement for testing. However, 
typing is a form of logical proof.  Logical proof is a way of 
demonstrating the absence of bugs, albeit an incomplete one. Testing is 
a way of demonstrating the absence of bugs, albeit an incomplete one.  
Testing establishes an upper bound on bugs, while proof/typing 
establishes a lower-bound.  Having robust options for both available 
lets developers pick one, the other, or both as appropriate for their 
project.


Does that mean "PHP is broken?"  No, that's an absurd strawman. Does 
being against union types or scalar types or property types mean "PHP is 
perfect?"  No, that's also an absurd strawman.


But there are unquestionably cases where robust typing is helpful. We 
should allow that, and encourage the development of more robust typing 
for those cases where it is helpful.  But completely untyped PHP is 
still 100% legal today and no one on this list is suggesting removing it.


Typing in PHP doesn't have to be a strict either/or.  That's what's so 
great about PHP's emerging type system: Typed and untyped code can 
coexist reasonably peacefully.


Can typed and untyped supporters do the same?  I hope so...

--
--Larry Garfield


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

Re: [PHP-DEV] [RFC] Nullable Types

[Fleshgrinder]

On 4/21/2016 1:00 PM, Lin Yo-An wrote:
> I think this is not to make PHP like Java, and it totally makes sense -
> Nullable should be a type of a type instead of a state. In Haskell it's
> named Maybe or Option, and It's better than NullPointerException.
> 
> Here is a discussion from Haskell community:
> https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html
> 

Why is it /better/?

final class None {}

final class Some {

public $value;

public function __construct($value) {
$this->value = $value;
}

}

final class Maybe {

private static $none;

private $value;

private function __construct($value) {
$this->value = $value;
}

public static function NOTHING() {
if (self::$nothing === null) {
self::$nothing = new Nothing();
}
return new static(self::$nothing);
}

public static function SOME($value) {
return new static(new Some($value));
}

public function hasSome(): bool {
return $this->value !== static::$none;
}

public function isNone(): bool {
return $this->value === static::$none;
}

public function unwrap() {
if ($this->value === static::$none) {
trigger_error('NullPointerException', E_USER_ERROR);
}
return $this->value->value;
}

}

// 

function f1(): Option {}

$x = f1();
if ($x->hasSome()) {
echo $x->unwrap(); // 42
}

$x = f1();
if ($x->isNone()) {
echo -1;
}

echo f1()->unwrap(); // error: NullPointerException :P

// 

function f2(): ?int {}

$y = f2();
if (isset($y)) {
echo $y; // 42
}

$y = f2();
if ($y === null) {
echo -1;
}

echo f2(); // null

You can easily build your own Option or Maybe and add the additional
bookkeeping to your runtime but it will not make your program more
secure or anything. It just adds more method calls and makes it more
verbose.

You can already use static code analyzers to detect if null is being
ignored in your code, however, right now they mainly have to rely on
PhpDoc that is often not properly documented. Adding an explicit syntax
to PHP for documentation would make PhpDoc obsolete and allow static
code analyzers to perform their job better and PHP to error out during
runtime if something else is being returned.

Honestly, null is not our problem. Every language has its null, just
because they wrap it or rename it does not make null suddenly vanish
from the universe. :P

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Types

[Fleshgrinder]

On 4/21/2016 6:33 PM, Thomas Bley wrote:
> Hello Tom,
> 
> with default return value I mean to return a certain value if nothing else is 
> returned (similar to method parameters with a default value).
> 
> example 1:
> 
> declare(strict_types=0);
> 
> function my_strpos(string $haystack, string $needle): int = false {
>   return 42; // return 42
>   return false; // return false
>   return true; // return 1
>   return; // return false
> }
> 
> example 2:
> 
> declare(strict_types=1);
> 
> function my_strpos(string $haystack, string $needle): int = false {
>   return 42; // return 42
>   return false; // return false
>   return true; // fatal error
>   return; // return false
> }
> 

I definitely do not like the equal sign in there because it goes against
all my mathematical knowledge; an int is false?!?

Note that the same /would/ be possible with union types if given precedence:

function fn(): int|false {}

That being said, it is way too magic! A return without an argument is
*void* and has to result in a `TypeError`. Really, start to think about
the types as /checked annotations/ ...

/**
 * @return int|false
 */
function fn() {}

function fn(): int|false {}

... are equivalent and the former does not suddenly return *false* on
its own and hell it shouldn't.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/20/2016 10:18 PM, Dominic Grostate wrote:
> Just a thought that crossed my mind which might satisfy both worlds.  Has
> anyone every considered unions as a type declaration?
> 
> namespace Vector/TypeDefs
> 
> union Stringable
> {
> as string;
> as int;
> as float;
> 
> private $value;
> 
> public function __make($type)
> {
> switch (type) {
> case 'string': return (string) $this->value;
> case 'int':return (int)$this->value;
> case 'float':  return (float)  $this->value;
> }
> }
> }
> 
> my_echo_func("123"); // << A scalar variable on the outside.
> 
> function my_echo_func(Stringable $stringable) // << a union on the inside
> {
> var_dump($stringable as string); // string(3) "123"
> var_dump($stringable as int);   // int(123)
> var_dump($stringable as float);  // float(123.0)
> }
> 
> Perhaps not exactly like this, but adding unions as type of class
> declaration should save a hell of a lot of keywords, and may save a number
> of "instanceof" type checks as well.
> 

I do not like the idea because these types directly become part of your
public API and you end up including a dozen packages just to get the
basic union types in. More IO, more cache utilization, more
dependencies, ...

Also, one cannot change any type that was ever declared without a direct
BC. No, sorry, I thing that this is very bad. :(

However, the idea to make objects castable to more of the various scalar
types is not new and would be awesome.

interface Object {

  function __toBool(): bool;
  function __toFloat(): float;
  function __toInt(): int;
  function __toString(): string;

  function __toArray(): array;
  function __toObject(): object;
  function __toResource(): resource;

}

Auto-conversion only if not ambiguous (`$o1 + $o2` where both have
`__toInt()` and `__toFloat()` throws an ?Error but `(float)$o1 +
(float)$o2` works so does `intdiv($o1, $o2)`), next is operator
overloading. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Quick sanity check ...

[Fleshgrinder]

On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
> No of course not. The specific instance of error you had *this time* may
> be solved. The problem won't be. You still have to deal with:
> - How this object is initialized? How you ensure it *is* initialized and
> that initialization is correct (0 is perfectly valid int)?
> - How this object is unserialized and what if unserialized data has
> non-integer or 0 or __wakeup has a bug?
> - What if some code just writes 0 into $olderThan - you declared it as
> public so anybody could mess with it?
> - What if some code mixes signed and unsigned and you get negative
> number instead of positive?
> - What if this code runs on 32-bit but receives 64-bit value and
> truncates it?
> 
> And so on, and so forth, I probably missed more possibilities than I
> mentioned. Declaring a type does not magically free one from correct
> design and testing, and typed programs have bugs as much as non-typed
> ones (maybe slightly different ones). Actually, one of the harms relying
> on it would be the same problem safe_mode had - it's full of holes, it's
> not safe and it creates wrong expectations. If you just write "int" and
> expect your problems to magically go away - you're in for big and bad
> surprises.
> 

While I agree with Stanislav and the others that a stricter type system
would not have prevented the bug. However, a stricter type system helps
to limit the amount of tests one has to perform and that is often a good
thing. That does not mean that dynamic type systems are shit. Actually
the opposite is the case, it is the same situation with paradigms.

What I love about PHP is that we have a lot under one hood:
multi-paradigm as well as loose and strict types. This allows one to
choose the best tool for the current job.

Relying on your language for a bit of safety as asked of it cannot be
compared to `safe_mode` where magic happens in the background. When one
declares and `int` than it should be an `int`. Of course that also means
that one should know what an `int` is and how to validate it according
to the current business rules.

That being said, isn't Lester's goal to validate scalar strings all the
time anyways? I mean, at least `mysqlnd` transforms all data from the DB
automatically to the proper scalar types for optimal performance in your
program. But if one keeps scalar strings everywhere and leaves proper
type coercion to PHP, I mean, why not. It is definitely doable and
strict types are definitely not necessary if done properly.

The big difference I see is that Lester is working on his code for
himself (or for a customer) and does not have to design APIs for
hundreds of other developers. PHP is used in the way it was initially
designed, as a glue language. I repeat myself but I cannot see the need
for strict types here.

If you are developing APIs that are going to be (ab)used by hundreds of
other developers in ways you would never have foreseen things change.
One wants to ensure that the API is as self-explanatory as possible and
as easy to use as possible. This includes (to get back to one of your
examples) that objects that should not be serialized are not
serializable (`private function __sleep()`) and not deserializable
(`private function __wakeup()`) nor cloenable if necessary. This
includes self-explanatory required types, sane default values, and
appropriate visibility of things.

PhpDoc is the classical tool for us here and Stanislav wrote in another
thread that this is the tool of choice. I completely disagree with this
because PhpDoc might be nice and already features more complicated types
(e.g. unions), however, it is also lacking many features as the
development of the PSR-5 shows. Another problem is that documentation is
not kept in sync and it is extremely hard to teach people how important
proper documentation is. Believe me, I know. You might say now that
those programmers are bad, well, yes, maybe. But that is what you get
when you are working in huge teams; ask Google.

In the end it is about better APIs for me as I explained in many other
messages and I stay true to that. :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Quick sanity check ...

[Fleshgrinder]

On 4/21/2016 2:52 AM, Lester Caine wrote:
> PHP5.4 http://lsces.org.uk/   0.41s 3.65Mb
> PHP5.6 http://php6.lsces.org.uk/  0.54s 11.77Mb
> PHP7   http://php7.lsces.org.uk/  0.45s 1.83Mb
> 
> Same set of code ... 3 different fpm instances
> PHP5.2 one with eaccelerator will not run :( but I think I now have PHP7
> configured properly with OPcache but it still does not match the speeds
> I get on the PHP5.2/eaccelerator production machines!
> 

Well, hard to tell if you could improve further without any info on
setup and/or configuration but the numbers look good to me. Also, do not
forget that the times and memory consumption you get from PHP might not
reflect the real world. I would suggest to measure this with independent
tools.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-21

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-21 06:28:31+03:00
commit: ecf6392
previous commit:23a4342
revision date:  2016-04-21 02:50:14+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.23%  0.40%  1.25%  
  6.84%
:-|   Drupal 7.36 cgi -T1  0.21%  0.13%  0.35%  
  3.96%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.03%  1.66%  
  3.17%
:-|   bench.php cgi -T100  0.01%  0.31% 25.63%  
  0.60%
:-|  micro_bench.php cgi -T10  0.14%  0.03%  6.24%  
  3.32%
:-|  mandelbrot.php cgi -T100  0.02% -0.29% 28.77%  
  6.63%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-04-21/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

AW: [PHP-DEV] [RFC:generics]

[Robert Stoll]

Hi Rasmus

 
> Hello internals,
> 
> I'd like to introduce an RFC proposing the addition of generic types and 
> functions:
> 
> https://wiki.php.net/rfc/generics
> 
> Ben Scholzen started this RFC as a quick draft with a few code samples in 
> August last year, and I have since then worked
> with Dominic and Ben towards a more complete, detailed RFC.
> 
> There are a few holes still, which is why it hasn't moved from Draft to Under 
> Discussion yet, but we feel that it's complete
> enough that we can start a discussion about this feature and try to iron out 
> the remaining details.
> 
> The RFC was previously "unofficially" announced on reddit - this thread 
> generated some good questions and may answer
> some of the most immediate questions:
> 
> https://www.reddit.com/r/PHP/comments/3zx8qs/php_rfcgenerics_update_03_please_comment/
> 
> One of the most common criticisms we've heard, is that the syntax would be 
> hard to implement, a few have said
> "impossible" - but we feel that, if generics are introduced, it's important 
> that the syntax and features be as familiar as
> possible to developers who are experienced with other mainstream web industry 
> languages, such as C# and Java.
> 
> To that end, Dominic Grostate has worked through most of the tokenizer/parser 
> issues - save for one very exotic edge
> case, his fork demonstrates that the proposed syntax can be parsed:
> 
> https://github.com/orolyn/php-src/commits/generics
> 
> Note that this fork is by no means an implementation of generics - it is 
> proof of concept as far as being able to parse the
> syntax.
> 
> We're hoping to find someone, with more experience working on the php 
> codebase, who is willing to collaborate on
> further implementation - and we do also have a partial test-suite, defining 
> the big picture expectations for most of the
> proposed language features:
> 
> https://github.com/orolyn/php-src/tree/generics-tests/Zend/tests/generics
> 
> We look forward to your comments, questions and (I'm sure) criticisms of this 
> proposal!
> 
> Thank You,
> 
> Regards,
>Rasmus Schultz
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
> http://www.php.net/unsub.php

Some questions about bounds checking:
- Example A: why don't you pass T (instead of Computer) to MachineBuilder? Just 
for the example or is it not possible with your approach?
- What about lower bounds?

In you examples about type checking you write:
> var_dump($hat_box instanceof Box); // => (bool) true
Will you support "raw types" similar as in Java, if so why?

you wrote:
> TODO: decide whether or not bounded polymorphism should be supported.

I am a bit confused, isn't parametric polymorphism combined with upper bounds 
already bounded polymorphism?



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

Re: [PHP-DEV] [RFC] Nullable Types

[Thomas Bley]

Hello Tom,

with default return value I mean to return a certain value if nothing else is 
returned (similar to method parameters with a default value).

example 1:

declare(strict_types=0);

function my_strpos(string $haystack, string $needle): int = false {
  return 42; // return 42
  return false; // return false
  return true; // return 1
  return; // return false
}

example 2:

declare(strict_types=1);

function my_strpos(string $haystack, string $needle): int = false {
  return 42; // return 42
  return false; // return false
  return true; // fatal error
  return; // return false
}

Regards
Thomas


f...@thefsb.org wrote on 21.04.2016 15:05:

> Hi Thomas,
> 
> 
> What is a default return declaration? Is this for branches within the function
> that do not lead to a return statement?
> 
> 
> Tom
> 
> 
> 
> 
> 
> From: Thomas Bley
> Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM
> To: guilhermebla...@gmail.com, cornelius.h...@gmail.com, dmi...@zend.com
> Cc: f...@thefsb.org, internals@lists.php.net
> 
> 
> 
> 
> 
> What do you think about default return values?
> 
> e.g.
> 
> function foo(): db_result = null {
> }
> 
> function canLogin(): bool = false {
> }


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

Re: [PHP-DEV] Safe timeout handling

[Julien Pauli]

On Wed, Apr 20, 2016 at 12:58 PM, Dmitry Stogov  wrote:
> Hi,
>
>
> It's a well known PHP problem, that exceeding of execution time-out 
> (max_execution_time) may lead to unexpected crashes.
>
> They occur because PHP may be interrupted in inconsistent state, and attempt 
> to release allocated by request resources leads to failure.
>
> Almost any big site sees these crashes from time to time.
>
>
> I propose to delay actual request termination until a "safe" point in 
> interpreter.
>
> Signal handler will just set EG(timed_out) flag.
>
> Interpreter will check this time from time to time (on jumps and calls that 
> may make loops or recursion) and perform the actual termination.
>
> This approach already works in PHP for Windows.
>
>
> In addition I introduce hard_timeout (default value 2 seconds).
>
> In case the "soft" timeout wasn't handled "safely" in that 2 seconds (because 
> of long running internal function), PHP process will be terminated without 
> attempt to free any resources.
>
> ZTS build will ignore "hard_timeout" (in the same way as PHP on Windows do).
>
>
> The PR: https://github.com/php/php-src/pull/1876
>
>
> It removes "exit_on_timeout" ini directive, and introduces "hard_timeout" 
> instead.
>
> Additional checks in VM make 0.5-1% slowdown in term of instruction retired 
> reported by callgrind.
>
> I think we don't need RFC for this. This is a long time desired fix.
>
>
> The same "interrupt" handling mechanism in the future may be reused for TICK 
> and signal handling.
>
>
> Thanks. Dmitry.


Hi !

Good new.

No RFC needed, but that breaks ABI and could impact extensions.
So, 7.1 as target is OK, not 7.0


Julien.P

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

Re: [PHP-DEV] [RFC:generics]

[Rowan Collins]

guilhermebla...@gmail.com wrote on 21/04/2016 16:25:
I understand others mentioned we could create a new interface that 
wraps the other two interfaces, but that still doesn't solve the 
problem where I want to extend a class AND also implement a specific 
interface.


I covered this case in my previous mail: you can create an abstract 
class that extends a concrete class and adds an interface to it, and the 
extra methods are implicitly added as abstract for descendants to implement:


// This could be somewhere else in code you don't want to touch
class Foo { public function doStuff() { /* ... */ } }
interface Bar { public function neededAction(); }

// Wherever you need to use the intersection Foo & Bar
abstract class FooBar extends Foo implements Bar {}
class Foo { /* can rely on both T#doStuff and 
T#neededAction existing */ }


// The implementation of the intersection must be in our control, to use 
"FooBar" rather than "Foo" as a base
// This is also true of extending interfaces, since PHP doesn't do 
duck-typing of interfaces
class FooBarImplementation extends FooBar { public function 
neededAction() { /* ... */ } }



What happens if the initial one get approved but it is too late to 
propose the subsequent one? Then PHP 7.1 would be released with a 
partial implementation and not fully featured as it should.


No other part of the language allows such type algebra, so a generics 
implementation that doesn't allow it wouldn't feel "incomplete" to 
anyone who wasn't aware of the discussion. Do you consider the typehints 
PHP has had for over a decade to be "a partial implementation" because 
they don't include this feature?


I'm assuming that if generics passed, and type algebra passed, then 
generics-with-type-algebra would go through on the nod and make it to 
the same version.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC:generics]

[Dominic Grostate]

Nope, it pretty much made perfect sense to me the first time.  But you may
get your wish in it going in with the proposal anyway as I don't think this
RFC is going to make it in time for the 7.1 window.

My crack at implementing it went bust when I realised I was adding too many
execute globals.

Speaking of implementation though.  Does anyone have a fairly good idea on
how to do it?  I got the parser ambiguity out of the way, but my attempts
at building the complete feature were mostly experimental.  So I'd like to
get an idea of how likely it is someone else will be able to take over.
On 21 Apr 2016 4:25 p.m., "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:

> I see that some of you are confusing union types with intersecting types
> here. The idea is not an OR, but an AND.
> I'll repeat the same example again to try to exemplify what I mentioned:
>
> class AA {}
> interface B {}
> interface C {}
> class BB extends AA implements B {}
> class CC extends AA implements B, C {}
>
> class Foo {}
> class Bar {}
>
> Class Foo means an intersecting type, where only class CC is applicable
> there. Class Bar means a union type, whee both AA, BB and CC are
> applicable.
>
> I understand others mentioned we could create a new interface that wraps
> the other two interfaces, but that still doesn't solve the problem where I
> want to extend a class AND also implement a specific interface.
> Surely this can be a subsequent RFC, but I see that as a deficiency of the
> currently proposed one and consider it incomplete. What happens if the
> initial one get approved but it is too late to propose the subsequent one?
> Then PHP 7.1 would be released with a partial implementation and not fully
> featured as it should.
>
>
> Regards,
>
>
> On Wed, Apr 20, 2016 at 11:18 PM, Jesse Schalken 
> wrote:
>
> > On Thu, Apr 21, 2016 at 8:56 AM, Rowan Collins 
> > wrote:
> > >
> > > I'm not quite sure what bounds would mean for anything other than
> classes
> > > or interfaces. A generic type that specified that its type parameter
> must
> > > be an int seems to me to be a non-generic type, because nothing other
> > than
> > > an int "is int". How is "class Foo { public function
> > > __construct(T $arg) { ... } }" different from just saying "class Foo {
> > > public function __construct(int $arg) { ... } }"? (Unless there were
> some
> > > kind of overloading, such that you could also have Foo, but
> > > please let's not go there...)
> > >
> >
> > Sticking with your example for a moment, if the type parameter is an
> "int",
> > then the only type that can *currently* be expressed in the type language
> > that is a subtype of "int" is "int", so it's not very useful *right now*.
> > However, a possible introduction of integer literal types would change
> > that, especially in combination with unions. This would enable you to
> > express the type "1|2|3", i.e. only one of those three integers. This
> would
> > be useful to typecheck enums, which are typically an "int" or "string"
> > which only accepts a finite set of values. As such, the type parameter "T
> > is int" could be filled with "int" or "1" or "0|1|2". (Imagine a class
> > "Bar" and various subclasses which each must select a single
> > integer as kind of tag, "Foo extends Bar<1>", "Baz extends Bar<2>" etc. I
> > do this in TypeScript with string literal types all the time.)
> >
> > Beside from that, the introduction of any one of union types,
> intersection
> > types, generic array types or callable types would mean the type
> constraint
> > for a generic type can usefully be something besides a single
> > class/interface. For example, if "" were written
> > "" I would expect to be able to do "$t
> > instanceof array|Traversable", but I wouldn't be able to unless
> > "instanceof" is intended to and is extended to support arbitrary types.
> >
> > Note that generic arrays are out of scope of the current RFC anyway, so
> > > it's possible that "$t instanceof array" could be added at the
> same
> > > time as "Foo>", presumably with the meaning
> that
> > > "array" would be considered to pass the check.
> > >
> > > Regards,
> > >
> > > --
> > > Rowan Collins
> > > [IMSoP]
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>

Re: [PHP-DEV] [RFC:generics]

[guilhermebla...@gmail.com]

I see that some of you are confusing union types with intersecting types
here. The idea is not an OR, but an AND.
I'll repeat the same example again to try to exemplify what I mentioned:

class AA {}
interface B {}
interface C {}
class BB extends AA implements B {}
class CC extends AA implements B, C {}

class Foo {}
class Bar {}

Class Foo means an intersecting type, where only class CC is applicable
there. Class Bar means a union type, whee both AA, BB and CC are applicable.

I understand others mentioned we could create a new interface that wraps
the other two interfaces, but that still doesn't solve the problem where I
want to extend a class AND also implement a specific interface.
Surely this can be a subsequent RFC, but I see that as a deficiency of the
currently proposed one and consider it incomplete. What happens if the
initial one get approved but it is too late to propose the subsequent one?
Then PHP 7.1 would be released with a partial implementation and not fully
featured as it should.


Regards,


On Wed, Apr 20, 2016 at 11:18 PM, Jesse Schalken 
wrote:

> On Thu, Apr 21, 2016 at 8:56 AM, Rowan Collins 
> wrote:
> >
> > I'm not quite sure what bounds would mean for anything other than classes
> > or interfaces. A generic type that specified that its type parameter must
> > be an int seems to me to be a non-generic type, because nothing other
> than
> > an int "is int". How is "class Foo { public function
> > __construct(T $arg) { ... } }" different from just saying "class Foo {
> > public function __construct(int $arg) { ... } }"? (Unless there were some
> > kind of overloading, such that you could also have Foo, but
> > please let's not go there...)
> >
>
> Sticking with your example for a moment, if the type parameter is an "int",
> then the only type that can *currently* be expressed in the type language
> that is a subtype of "int" is "int", so it's not very useful *right now*.
> However, a possible introduction of integer literal types would change
> that, especially in combination with unions. This would enable you to
> express the type "1|2|3", i.e. only one of those three integers. This would
> be useful to typecheck enums, which are typically an "int" or "string"
> which only accepts a finite set of values. As such, the type parameter "T
> is int" could be filled with "int" or "1" or "0|1|2". (Imagine a class
> "Bar" and various subclasses which each must select a single
> integer as kind of tag, "Foo extends Bar<1>", "Baz extends Bar<2>" etc. I
> do this in TypeScript with string literal types all the time.)
>
> Beside from that, the introduction of any one of union types, intersection
> types, generic array types or callable types would mean the type constraint
> for a generic type can usefully be something besides a single
> class/interface. For example, if "" were written
> "" I would expect to be able to do "$t
> instanceof array|Traversable", but I wouldn't be able to unless
> "instanceof" is intended to and is extended to support arbitrary types.
>
> Note that generic arrays are out of scope of the current RFC anyway, so
> > it's possible that "$t instanceof array" could be added at the same
> > time as "Foo>", presumably with the meaning that
> > "array" would be considered to pass the check.
> >
> > Regards,
> >
> > --
> > Rowan Collins
> > [IMSoP]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] [RFC] Nullable Types

[fsb]

+1 to what Dmity wrote.




I prefer not to have ?Something argument hints but I acknowledge that others 
want it.




Tom





From: Dmitry Stogov
Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎13‎ ‎PM
To: guilhermebla...@gmail.com, Lin Yo-An
Cc: Tom Worster, internals






What we really miss now, is an ability to define nullable return types.




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




I don't care about the same notations for arguments (and everything else), 
because we already may use NULL default value.


However usage of "?" for arguments also may make sense. Someone may like this, 
someone not.




Thanks. Dmitry.





 
From: guilhermebla...@gmail.com 
Sent: Wednesday, April 20, 2016 18:05
To: Lin Yo-An
Cc: Dmitry Stogov; Tom Worster; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types 
 


I read the RFC and I want to highlight why I'll vote -1 on it even before it 
goes to voting.  



IMHO, it looks backwards to what the language is progressing. The introduction 
of nullable type hint as a separate notation than a simple type hint makes it 
*very* hard to implement typed properties, factory methods and constructor 
verifications. 



Dmitry is even involved in the discussion of having IS_UNDEF until constructor 
ends, then enforcing type hinting at the end of constructor to trigger 
potential invalid instance state. It created a mess in the internal structure 
by creating a 3-state value: uninitialized, absent of value (null) and assigned 
value. All this problem would be solved by merging null into accepted value.

So far the proposed solution there to take a wrong assumption to assume a 
default value based on type defined (like int = 0, string = '', etc), which are 
all potential valid values, leading to unpredictable behavior if a develop 
misses to assign a value to that property.




Sure, people will say that now PHP will require a NullPointerException, PHP is 
turning into Java, or that I don't know what I'm talking about because they 
coded for Amiga and I don't (yes, I've seen that already in this mailing list). 
But the fact is that keeping control of 3-state flags are hard to maintain.




Constructor verifications is actually a completely different subject that 
shouldn't be considered as part of typed properties, but for final properties 
(or whoever other keyword someone think is smarter because *reasons*). It's bad 
to bring this already to typed properties, specially because of its runtime 
performance impact.




Now let's say we move forward with nullable type hint, ignore everything what I 
said and move forward. Congratulations, we just created a language 
inconsistency. Example:




function foo(Bar $bar = null);




Why now I have 2 ways to define a nullable value? Shouldn't this be changed 
into this:




function foo(?Bar $bar);




But of course, changing this would be a BC break and should be left for 
*reasons*. But accepting the absence of value (null) as a valid value, it would 
address the language inconsistency (the current support would be kept, so no BC 
break), and would solve a huge mess that typed properties patch currently needs 
to solve. Ah, and we don't continue into this path of madness where same thing 
have 144 different ways in different areas to be defined.







Regards,



On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An  wrote:

On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov  wrote:

> The grammar is taken from HHVM.
> Using any other would make more mess.
>
I agree






-- 



Guilherme Blanco


Lead Architect at E-Block

Re: [PHP-DEV] [RFC] Nullable Types

[fsb]

Hi Thomas,


What is a default return declaration? Is this for branches within the function 
that do not lead to a return statement?


Tom





From: Thomas Bley
Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM
To: guilhermebla...@gmail.com, cornelius.h...@gmail.com, dmi...@zend.com
Cc: f...@thefsb.org, internals@lists.php.net





What do you think about default return values?

e.g.

function foo(): db_result = null {
}

function canLogin(): bool = false {
}

Re: [PHP-DEV] [RFC:generics]

[Rowan Collins]

Jesse Schalken wrote on 21/04/2016 04:18:


Sticking with your example for a moment, if the type parameter is an 
"int", then the only type that can /currently/ be expressed in the 
type language that is a subtype of "int" is "int", so it's not very 
useful /right now/. However, a possible introduction of integer 
literal types would change that, especially in combination with 
unions. This would enable you to express the type "1|2|3", i.e. only 
one of those three integers. This would be useful to typecheck enums, 
which are typically an "int" or "string" which only accepts a finite 
set of values. As such, the type parameter "T is int" could be filled 
with "int" or "1" or "0|1|2". (Imagine a class "Bar" and 
various subclasses which each must select a single integer as kind of 
tag, "Foo extends Bar<1>", "Baz extends Bar<2>" etc. I do this in 
TypeScript with string literal types all the time.)


I'm struggling to follow this example; it seems like you are using the 
type parameter to supply actual data to the implementation, which goes 
rather beyond generics, and into full-blown template metaprogramming. 
I'm not sure why you'd ever need the sub-class to compile in a value 
that way rather than just overriding a method somewhere, and would need 
some convincing that PHP needed this kind of complexity.



Beside from that, the introduction of any one of union types, 
intersection types, generic array types or callable types would mean 
the type constraint for a generic type can usefully be something 
besides a single class/interface. For example, if "array|Travarsable>" were written "" I 
would expect to be able to do "$t instanceof array|Traversable", but I 
wouldn't be able to unless "instanceof" is intended to and is extended 
to support arbitrary types.


This is a stronger argument, although I think extending the instanceof 
operator might be a good idea in that case anyway - otherwise, we would 
have a constraint that you can assert (produce a TypeError at a function 
boundary) but not easily test for. To avoid replicating the engine's 
entire checking routine, you'd end up doing this:


function ugly_instance_of($value): boolean {
try {
return (function(T $checked) { return true; })($value);
}
catch ( TypeError $e ) {
return false;
}
}

if ( ugly_instance_of($x) ) // if ( $x instanceof array )

*shudder* ;)

Regards,
--
Rowan Collins
[IMSoP]

RE: [PHP-DEV] Safe timeout handling

[Anatol Belski]

Hi Dmitry,

> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Wednesday, April 20, 2016 12:58 PM
> To: Nikita Popov ; Rasmus Lerdorf
> ; Anatol Belski ; Antony Dovgal
> ; Zeev Suraski ; Xinchen Hui
> 
> Cc: internals 
> Subject: [PHP-DEV] Safe timeout handling
> 
> Hi,
> 
> 
> It's a well known PHP problem, that exceeding of execution time-out
> (max_execution_time) may lead to unexpected crashes.
> 
> They occur because PHP may be interrupted in inconsistent state, and
attempt
> to release allocated by request resources leads to failure.
> 
> Almost any big site sees these crashes from time to time.
> 
> 
> I propose to delay actual request termination until a "safe" point in
interpreter.
> 
> Signal handler will just set EG(timed_out) flag.
> 
> Interpreter will check this time from time to time (on jumps and calls
that may
> make loops or recursion) and perform the actual termination.
> 
> This approach already works in PHP for Windows.
> 
> 
> In addition I introduce hard_timeout (default value 2 seconds).
> 
> In case the "soft" timeout wasn't handled "safely" in that 2 seconds
(because of
> long running internal function), PHP process will be terminated without
attempt
> to free any resources.
> 
> ZTS build will ignore "hard_timeout" (in the same way as PHP on Windows
do).
> 
> 
> The PR: https://github.com/php/php-src/pull/1876
> 
> 
> It removes "exit_on_timeout" ini directive, and introduces "hard_timeout"
> instead.
> 
> Additional checks in VM make 0.5-1% slowdown in term of instruction
retired
> reported by callgrind.
> 
> I think we don't need RFC for this. This is a long time desired fix.
> 
> 
> The same "interrupt" handling mechanism in the future may be reused for
TICK
> and signal handling.
> 
I've tested your patch with CLI, mpm_prefork, mpm_worker and mpm_winnt and
see no regressions. The existing tests in tests/*/*timeout*.phpt pass as
well. We'd probably need to add some more with respect to the new INI option
and more extensive testing under high load.

AFM it's a good step towards unifying the timeout handling and making it
safer. Even better if ticks and exceptions handling can be later improved by
the same approach. 

Regards

Anatol


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

Re: [PHP-DEV] [RFC] Nullable Types

[Lin Yo-An]

On Wed, Apr 20, 2016 at 11:05 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
>
> Dmitry is even involved in the discussion of having IS_UNDEF until
> constructor ends, then enforcing type hinting at the end of constructor to
> trigger potential invalid instance state. It created a mess in the internal
> structure by creating a 3-state value: uninitialized, absent of value
> (null) and assigned value. All this problem would be solved by merging null
> into accepted value.
> So far the proposed solution there to take a wrong assumption to assume a
> default value based on type defined (like int = 0, string = '', etc), which
> are all potential valid values, leading to unpredictable behavior if a
> develop misses to assign a value to that property.
>

> Sure, people will say that now PHP will require a NullPointerException,
> PHP is turning into Java, or that I don't know what I'm talking about
> because they coded for Amiga and I don't (yes, I've seen that already in
> this mailing list). But the fact is that keeping control of 3-state flags
> are hard to maintain.
>

I think this is not to make PHP like Java, and it totally makes sense -
Nullable should be a type of a type instead of a state. In Haskell it's
named Maybe or Option, and It's better than NullPointerException.

Here is a discussion from Haskell community:
https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html

-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] PHP 7.1 roadmap

[Julien Pauli]

On Tue, Apr 12, 2016 at 10:20 PM, Scott Arciszewski  wrote:
> On Tue, Apr 12, 2016 at 2:29 PM, Anatol Belski  wrote:
>>
>> Hi,
>>
>> Time goes by fast - no sooner 7.0 was unleashed on the world than 7.1
>> bangs
>> at the door.  I would like to bring a couple of points regarding this.
>>
>> There is enough time yet, but it would make full sense all the RFC authors
>> targeting 7.1 to finalize the work and get the RFC voted. Or the RFCs,
>> that
>> have not been discussed yet - still some time is there to go through the
>> full RFC process and get them ready for 7.1. It is anyway the right moment
>> to intensify the discussions and work on 7.1 features and patches.
>>
>> It looks also like the right time to elect the 7.1 RMs. Please everyone
>> interested to run for 7.1 RMs announce your candidacy to this thread. I
>> would suggest to start the poll on this two weeks after this message, with
>> the two weeks vote period.
>>
>> The prerelease cycle start could then happen already in June (or July,
>> depends whether one wants to wait till 5.5 EOL). Anyway, having the new
>> RMs
>> team we can start to plan and proceed with the 7.1 prerelease cycle.
>>
>> Thanks
>>
>> Anatol
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Yikes, time really flies.
>
> The new ext/sodium is out, so I suppose it's high time to get that RFC ready
> to be voted on.


Time runs :-)

Anyone for RMing 7.1 ?
We obviously need someone to volunteer :-p


Julien.Pauli

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

Re: [PHP-DEV] [RFC:generics]

[Josh Di Fabio]

On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
 wrote:
> Thanks for you're input everyone.
>
> So far, we have read some ideas for handling upper bounds, or multiple there
> of.
> The preferred keywords appear to be either "as" or "instanceof".
>
> class Foo {}
> class Foo {}
>
> We would like to know for sure then if everyone is largely against the
> addition of an "is" keyword, in favour of one of the other two.
>

I really don't like 'as' in this context, even if Hack uses it, as it
doesn't reflect in English terms what the code is doing. As others
have already said, it reads as if 'T' is being aliased to 'Bar'.

On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate
 wrote:
> Thanks for you're input everyone.
>
> So far, we have read some ideas for handling upper bounds, or multiple there
> of.
> The preferred keywords appear to be either "as" or "instanceof".
>
> class Foo {}
> class Foo {}
>
> We would like to know for sure then if everyone is largely against the
> addition of an "is" keyword, in favour of one of the other two.
>
> 
>
> There is also a desire to include unions and intersections.
> Presently though, this feature feels tied in with
> https://wiki.php.net/rfc/union_types meaning if union types are approved,
> then generics would have to support them as well.  Likewise if this feature
> becomes approved in generics, it would make sense to support them in regular
> type hints as well.
>
> 
>
> The RFC makes a reference to generic closures, which may look something like
> this:
>
> function my_function(callable $func) {
>
> }
>
> However, an RFC already exists which is very similar to this feature at
> https://wiki.php.net/rfc/callable-types
> As it currently standards these RFCs appear incompatible with each other
> (please correct me if I am wrong).
>
> My question about this is would you prefer the generics RFC exclude this
> part in favour of a separate or later RFC.
> Initially the proposal included generic arrays "array".  However to
> ease the implementation it was decided that should be a separate feature.
> So we'd like to find out if everyone else feels the same way about callable
> types.
>
> 
>
> This RFC currently doesn't specify in detail how reflection would work.  We
> have attempted a few API designs, but due to generic classes being ...
> generic, it is difficult to find a suitable way to glean information about a
> class in a backwards compatible manner.  So we will need some help on this
> one.
>
> -
>
> Aside from these top issues on our own list, however does everyone feel
> about the proposal in general?
> As the RFC is still in draft, we will continue to make changes to it as more
> popular idea pop up, so please continue.
>
> Thanks.
>
> PS: I wasn't properly subscribed to the mailing list, so I missed a few
> important messages that were mailed directly to internals, but hopefully
> I've managed to fix that now.

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