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

[Jesse Schalken]

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

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

[Lester Caine]

On 20/04/16 21:11, Fleshgrinder wrote:
> I do not see a single reason why you would need to change anything if
> you are not requiring any of the new features and would say that the
> only reason to upgrade for you is security patches.
> 
> However, I hardly believe that you cannot see a speed improvement; or at
> least less memory consumption.

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!

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

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

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

[Mathieu Rochette]

On 04/20/2016 09: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 don't mind having a new keyword and is would be my first choice because
using one of the other two would feel odd. in T instanceof Bar I expect
T to be a
variable, not a type and with T as Bar I feel like I'm telling PHP "T is
not a Bar but
treat as if it is"
I'm not that well aware of the implication of adding a new keyword but I
thought
it would not be a big deal since
https://wiki.php.net/rfc/context_sensitive_lexer
has passed (I'm not saying it's not important, just that using the most
appropriate
keyword is very important too)

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

-- 
Mathieu Rochette

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

[Lester Caine]

On 20/04/16 21:01, Stanislav Malyshev wrote:
>> The outcome is easy to grasp. Because it did not crash by a TypeError
>> > (which would also require the file to be declared as strict), and we lost
>> > 100k in sales. But PHP does not need more strictness...
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.

I was thinking "so no one thought to check that the number was the right
size?" ... type checks are pointless if you can't even validate the data ...

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

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

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

[Rowan Collins]

On 20/04/2016 22:02, Jesse Schalken wrote:

"instanceof" implies to me that the right hand side is a class/interface
name, since that's what's expected with the "instanceof" operator, rather
than a type. If I can do "Foo>" I would expect to
be able to do "if ($t instanceof array) ...", but I can't.


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 Foois float>, but please let's not go there...)


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

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

[Patrick ALLAERT]

Zeev,

Le mar. 19 avr. 2016 à 11:56, Zeev Suraski  a écrit :

> In Drupal 8, many catch blocks simply resort to return FALSE or TRUE.  For
> example:
>
> try {
>   return $router->match($path);
> }
> catch (ResourceNotFoundException $e) {
>   return FALSE;
> }
> catch (ParamNotConvertedException $e) {
>   return FALSE;
> }
> catch (AccessDeniedHttpException $e) {
>   return FALSE;
> }
> catch (MethodNotAllowedException $e) {
>   return FALSE;
> }
>   }
>

This looks much more like Exceptions used for not "Exceptional" cases:
where Exceptions are preferred over a clean API and avoiding at all price
if-conditions.

One of the very reason I voted "no".

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


> try {
>   return $router->match($path);
> }
> catch
> (ResourceNotFoundException|ParamNotConvertedException|AccessDeniedHttpException|MethodNotAllowedException
> $e) {
>   return FALSE;
> }
>

The "return FALSE" here on all those cases is just another way to ease
silencing Exceptions which is often a bad idea (like @).

It's also perfectly possible to make all those Exceptions implement a
"MatchingFailedException" interface (even empty). This would even make the
collection reusable AND extensible because new user Exception classes could
implement that "MatchingFailedException" interface without the need to
refactor code.

Which is much, much nicer and readable.  And I found this in the ZF2
> codebase:
>
>  } catch (DiRuntimeException $e) {
>  if ($methodRequirementType & self::RESOLVE_STRICT) {
>  //finally ( be aware to do at the end of flow)
>  array_pop($this->currentDependencies);
>  if (isset($alias)) {
>  array_pop($this->currentAliasDependenencies);
>  }
>  // if this item was marked strict,
>  // plus it cannot be resolve, and no value exist,
> bail out
>  throw new Exception\MissingPropertyException(
>  sprintf(
>  'Missing %s for parameter ' . $name . '
> for ' . $class . '::' . $method,
>  (($value[0] === null) ? 'value' :
> 'instance/object')
>  ),
>  $e->getCode(),
>  $e
>  );
>  } else {
>  //finally ( be aware to do at the end of flow)
>  array_pop($this->currentDependencies);
>  if (isset($alias)) {
>  array_pop($this->currentAliasDependenencies);
>  }
>  return false;
>  }
>  } catch (ServiceManagerException $e) {
>  //
> Zend\ServiceManager\Exception\ServiceNotCreatedException
>  if ($methodRequirementType & self::RESOLVE_STRICT) {
>  //finally ( be aware to do at the end of flow)
>  array_pop($this->currentDependencies);
>  if (isset($alias)) {
>  array_pop($this->currentAliasDependenencies);
>  }
>  // if this item was marked strict,
>  // plus it cannot be resolve, and no value exist,
> bail out
>  throw new Exception\MissingPropertyException(
>  sprintf(
>  'Missing %s for parameter ' . $name . '
> for ' . $class . '::' . $method,
>  (($value[0] === null) ? 'value' :
> 'instance/object')
>  ),
>  $e->getCode(),
>  $e
>  );
> } else {
> //finally ( be aware to do at the end of flow)
> array_pop($this->currentDependencies);
> if (isset($alias)) {
> array_pop($this->currentAliasDependenencies);
> }
> return false;
> }
> }
>
> To save everyone some time, the two code blocks for the two exception
> types are completely identical.  I'm not sure why it wasn't
> function()alized, but regardless, it's another case where the new proposed
> feature would make perfect sense.
>
> I think saying that identical handling for multiple exception types is bad
> or is grounds for an urgent code review is fairly disconnected from reality
> in many if not most cases.
>
> Zeev
>
>
> --
> 

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

[Stanislav Malyshev]

> You're blaming humans (devs, testers etc) for a problem which could have
> been caught automatically (by a strictly enforced type annotation). It

This particular problem maybe could. But it is a symptom of a systemic
issue (bad design, bad testing) - curing symptom and leaving the disease
is like giving a painkiller to anybody who comes into a hospital without
actually seeing what's wrong with them. Usually doesn't end well.

> follows that you actually /want/ writing PHP software to be inefficient,
> labour intensive and error-prone.

Of course I do. I hate all humans and ones using PHP especially, that's
why I spend so many hours working on it for decades now. Kudos for
finally discovering my evil plan. Keep on the good work.
-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Stanislav Malyshev]

Hi!

> The question here is how type strictness would benefit the language. 
> I agree with you on most parts. But still... if the class was declared
> like this:
> 
> class CancelOutdatedOrdersDTO {
> public int $olderThan;
> }
> 
> Wouldn't that be solved entirely? Code would crash (through a

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.

-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Jesse Schalken]

"instanceof" implies to me that the right hand side is a class/interface
name, since that's what's expected with the "instanceof" operator, rather
than a type. If I can do "Foo>" I would expect to
be able to do "if ($t instanceof array) ...", but I can't.

I think unless the "instanceof" operator is updated to be able to do checks
with arbitrary type expressions, a different keyword should be used for
generic type constraints so as not to imply any misleading correspondence
with the "instanceof" operator.

So I would prefer "as". It's also shorter, and matches Hack.

On Thu, Apr 21, 2016 at 5:17 AM, Dominic Grostate <
codekest...@googlemail.com> 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.
>

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

[Zeev Suraski]

> On 20 באפר׳ 2016, at 23:33, Jesse Schalken  wrote:
> 
> You're blaming humans (devs, testers etc) for a problem which could have
> been caught automatically (by a strictly enforced type annotation). It
> follows that you actually *want* writing PHP software to be inefficient,
> labour intensive and error-prone.

Which is exactly why we're seeing a massive exodus from loosely typed languages 
like PHP and JavaScript towards strongly typed languages like Java, with people 
reporting radically better productivity.

Seriously.

We all know the advantages of strict typing.  What seems that we don't all know 
are the advantages of dynamic typing.  And it's no coincidence that in reality, 
the exodus is going in the other direction, and dynamically typed languages are 
reported to be a lot more productive.

Might you consider reading the research Johannes pointed to?

What made you choose PHP?  If you think it's fundamentals are so bad and push 
you to be inefficient, sentenced to hard labor and your code prone to errors, 
how did you make this horrible choice?

Zeev


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

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

[Jesse Schalken]

You're blaming humans (devs, testers etc) for a problem which could have
been caught automatically (by a strictly enforced type annotation). It
follows that you actually *want* writing PHP software to be inefficient,
labour intensive and error-prone.

On Thu, Apr 21, 2016 at 6:01 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Dominic Grostate]

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.

On 20 April 2016 at 20:55, Fleshgrinder  wrote:

> I am not quoting anything because the formatting of your emails is
> completely off in Thunderbird. However, I want to add one to the list:
>
> declare(strict_types=1);
>
> interface Stringable {
> function __toString(): string;
> }
>
> function fn(string|Stringable $arg) {
> $param = (string) $arg;
> }
>
> We could add a new *stringable* primitive to PHP though, but do we guys
> really want to start doing so? There is pretty much an endless amount of
> combinations and finding names alone is endlessly hard.
>
> declare(strict_types=1);
>
> function fn(int|string $maybe_bigint) {
> // mysqlnd automatically creates the proper type based on the value.
> // Expressing this in userland is impossible ... :(
> }
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

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

[Sara Golemon]

On Wed, Apr 20, 2016 at 12:17 PM, Dominic Grostate
 wrote:
> 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'm against adding a new keyword anywhere we can trivially avoid it,
and this is one of those places where avoidance is trivial.
Preference for 'as', since it conform's to HackLang's generics (and
it's fewer keystrokes), but 'instanceof' has enough clarity to it that
I wouldn't complain.

> 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.
>
IMO. This feature is complex enough without unions/intersections, and
they have the concurrency problem with the fact that the Union Types
RFC is also under discussion.  I think if both that RFC and this one
(without complex limits) both pass, then it makes sense to do a
followup RFC to combine them in logical ways.

> 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.
>
Callable is probably a bad use-case for this extension of generics,
but I'd like to see array at some later point.  That said, both
should be considered out of scope of this RFC in my opionion.

> 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.
>
I don't think Reflection necessarily needs to be part of the RFC, but
if we can come up with something which makes sense it doesn't have to
be out of scope.  Really, the in/ex-clusion of this part will come
down to whether or not someone comes up with a sane API for it.

> 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.
>
+1 from me.  This is an essential piece of being able to do
comprehensive static analysis of PHP programs, and static analysis has
already saved my butt more times than I care to count.

-Sara

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

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

[Fleshgrinder]

I do not see a single reason why you would need to change anything if
you are not requiring any of the new features and would say that the
only reason to upgrade for you is security patches.

However, I hardly believe that you cannot see a speed improvement; or at
least less memory consumption.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[guilhermebla...@gmail.com]

The question here is how type strictness would benefit the language.
I agree with you on most parts. But still... if the class was declared like
this:

class CancelOutdatedOrdersDTO {
public int $olderThan;
}

Wouldn't that be solved entirely? Code would crash (through a TypeError),
it would never be pushed to production and we would never have experienced
this problem.


PS: I just gave one example... we didn't actually loose 100k, but I had to
spend an hour manually addressing the sales back to pending status.

Regards,

On Wed, Apr 20, 2016 at 4:01 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>



-- 
Guilherme Blanco
Lead Architect at E-Block

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

[Ryan Pallas]

On Wed, Apr 20, 2016 at 2:01 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.
>

+1

>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Stanislav Malyshev]

Hi!

> The outcome is easy to grasp. Because it did not crash by a TypeError
> (which would also require the file to be declared as strict), and we lost
> 100k in sales. But PHP does not need more strictness...

In other words, somebody wrote code that is supposed to only accept ints
but does no checks. Somebody wrote tests that actually don't test
anything. Somebody signed off on code that was not properly designed or
tested to go into production. And the language is to blame. Right.

-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Jesse Schalken]

You can continue to use arrays for database records like you always have
been. None of the new or proposed features are going to stop you.

The concept of type annotations and type systems really has nothing to do
with databases directly. It's about adding certainty with regards to the
types that are flowing through your PHP program so the program can be
modified reliably and predictably. A database is just one possible thing
*outside* the program to connect to and interact with using some protocol.

Creating a mapping between database records and types PHP objects and types
in order to leverage PHP's type system for the purpose of using a databases
is quite a complex topic in and of itself, but basically amounts to using
some kind of object-relational-mapper such as Doctrine. However, I'm not
sure how recent or proposed improvements to typing is related. All I can
think of is that Doctrine could make use of type properties instead of
PHPDocs for getting column types.

You can also just continue to arrays, or a simple class with get($column)
and set($column, $value) methods. That's what I do. :P


On Thu, Apr 21, 2016 at 5:22 AM, Lester Caine  wrote:

> With all of the debate on the 'type system', can I just ask a probably
> silly question ;)
>
> I'm currently working on porting an application that has been running on
> windows as C++ code for 20 years. The main reason for changing is that
> While it worked fine when sites upgraded to XP, the move to W7 and later
> really needs all the code recompiled, something that will need a big
> cheque book to buy a current compiler set. So for many reasons a switch
> to web based using already existing tools makes perfect sense.
>
> The database is still running Firebird since the switch from interbase
> in the late 90's so all of the existing data can be maintained, and I
> already have a working base on which to build a new set of page
> templates. ( Only hole is the need for a decent javascript scheduler
> function to replace the desktop one :( )
>
> This is all running on SQL based schema's which have not changed in
> years, and ADOdb still quite happily produces arrays of results for
> which there is little point creating new 'objects', just simply handling
> the basic variable entries in the arrays just as I have for years. The
> various tools handle data validation, and 'null' is an essential
> component of that validation process. This does not need any of the
> overload of creating 'getters and setters' and I see little point trying
> to add any 'type' casting into the process since the validation layer
> simply works with the bog standard variables without and need for
> 'special cases'.
>
> So what benefit does all of the additional 'facilities' now being piled
> on give that would actually improve that process. I am now seeing a
> speed improvement on the PHP7 ports, but I'm not seeing any point to
> make any changes to code OTHER than making the PHP5.2 code clean on PHP7
> ... As Zeev has already said "PHP is not broken" ... Do I really need to
> change the way I work which is running fine for my clients?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[guilhermebla...@gmail.com]

I might answer you by given a scenario that happened this week here at work.

Because our non-broken language relies on a loose type system, a developer
of my company wrote a property that accepts null, int, string, object,
whatever as a property.

This property was declared in a class that is used in a console command
that runs weekly. This property was supposed to hold an integer (value in
hours) that would calculate a difference in time and cancel prospected
purchases older than this variable hours. All unit tests passed, because
they inspect the parts not the whole. By mistake, the developer forgot to
provide a value.
Nothing was reported in PHP because the language is not broken, and because
there's no final and no typed property, no error was reported and code
proceed execution. That value that was not initialized and got assigned as
null. This value was then converted to 0, and all purchases older than "now
- 0 hours" got cancelled.

The outcome is easy to grasp. Because it did not crash by a TypeError
(which would also require the file to be declared as strict), and we lost
100k in sales. But PHP does not need more strictness...


Regards,


On Wed, Apr 20, 2016 at 3:22 PM, Lester Caine  wrote:

> With all of the debate on the 'type system', can I just ask a probably
> silly question ;)
>
> I'm currently working on porting an application that has been running on
> windows as C++ code for 20 years. The main reason for changing is that
> While it worked fine when sites upgraded to XP, the move to W7 and later
> really needs all the code recompiled, something that will need a big
> cheque book to buy a current compiler set. So for many reasons a switch
> to web based using already existing tools makes perfect sense.
>
> The database is still running Firebird since the switch from interbase
> in the late 90's so all of the existing data can be maintained, and I
> already have a working base on which to build a new set of page
> templates. ( Only hole is the need for a decent javascript scheduler
> function to replace the desktop one :( )
>
> This is all running on SQL based schema's which have not changed in
> years, and ADOdb still quite happily produces arrays of results for
> which there is little point creating new 'objects', just simply handling
> the basic variable entries in the arrays just as I have for years. The
> various tools handle data validation, and 'null' is an essential
> component of that validation process. This does not need any of the
> overload of creating 'getters and setters' and I see little point trying
> to add any 'type' casting into the process since the validation layer
> simply works with the bog standard variables without and need for
> 'special cases'.
>
> So what benefit does all of the additional 'facilities' now being piled
> on give that would actually improve that process. I am now seeing a
> speed improvement on the PHP7 ports, but I'm not seeing any point to
> make any changes to code OTHER than making the PHP5.2 code clean on PHP7
> ... As Zeev has already said "PHP is not broken" ... Do I really need to
> change the way I work which is running fine for my clients?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

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

[Fleshgrinder]

I am not quoting anything because the formatting of your emails is
completely off in Thunderbird. However, I want to add one to the list:

declare(strict_types=1);

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
$param = (string) $arg;
}

We could add a new *stringable* primitive to PHP though, but do we guys
really want to start doing so? There is pretty much an endless amount of
combinations and finding names alone is endlessly hard.

declare(strict_types=1);

function fn(int|string $maybe_bigint) {
// mysqlnd automatically creates the proper type based on the value.
// Expressing this in userland is impossible ... :(
}

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Ryan Pallas]

On Wed, Apr 20, 2016 at 1:17 PM, Dominic Grostate <
codekest...@googlemail.com> 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 like instanceof the most, as I feel its more obvious. "is" is good IMO
from a user perspective, tho its a new keyword, its pretty obvious what's
happening (my T IS something, and will not be anything else). "as" makes me
feel like its going to either type-cast or T is going to be aliased as Bar
for later use in the class definition.


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

Agreed, I think this should be left until after both RFCs have been decided
on.


>
> 
>
> 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 makes sense to me to leave it separate. Lets get generic classes first.


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

I think the RFC looks pretty great. I think you guys have put in a lot of
very good work speccing it out, thanks for that. As generics are the
biggest thing I feel missing that I use elsewhere, I really hope this
change gets accepted and fully working implementation!


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

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

[Fleshgrinder]

On 4/19/2016 10:19 PM, Zeev Suraski wrote:
> I can only repeat - primitive types can and should get dedicated solutions.  
> There's really no need for allowing over creativity with userland-customized 
> scalar types.  If we think that a certain scalar definition makes a lot of 
> sense, we can add it at the language level.  There's no need to complicate 
> the language, add syntax which makes no sense for objects and isn't really 
> needed for scalars either.
> 

We can for many:

type number := int|float
type object := 
type scalar := bool|int|float|string
...

However, what about:

type ? := array|Traversable
type ? := int|string
type ? := float|string
type ? := bool|null
...

I actually argue that we do not even want to define them on a language
level (with the exception of array|Traversable) because these
combinations are too usecase specific.

>> interface HouseCat {
>> function drink();
>> }
>>
>> interface Dog {
>> function eat();
>> }
>>
>> -interface Lion {
>> +interface Lion extends HouseCat, Dog{
>> function drink();
>> function eat();
>> }
> 
> Pardon me saying this but it doesn't appear as if you've read what I wrote.  
> Please take a look at the 'diff' I made in the definition of your Lion class, 
> because without it, your sample and mine have little to do with each other.
> 
> With that change in place, please reevaluate whether what you said is 
> relevant:
> 

I guess I just jumped over that fact and misinterpreted it because what
you are proposing is a magic intersection type limited to interfaces.
While I cannot think of a situation where this creates problems from a
technical point of view (it is duck typing after all) I find it highly,
highly unusual and way too magic as well as even confusing.

I think there are two ways:

- No union/intersection at all!
+ Union and intersection!

Going somewhere in between destroys generics, bounded quantification,
and F-bounded quantification in the future or at least makes it harder
to implement cleanly. You need to consider that this RFC might be voted
negative but it might come back in PHP 8 or PHP 9 where the landscape
has changed so vastly that it might become a yes.

Let's not introduce half backed features that nobody ever implemented
and found useful in any context or we end up with more weirdness that we
already have a some points.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Quick sanity check ...

[Lester Caine]

With all of the debate on the 'type system', can I just ask a probably
silly question ;)

I'm currently working on porting an application that has been running on
windows as C++ code for 20 years. The main reason for changing is that
While it worked fine when sites upgraded to XP, the move to W7 and later
really needs all the code recompiled, something that will need a big
cheque book to buy a current compiler set. So for many reasons a switch
to web based using already existing tools makes perfect sense.

The database is still running Firebird since the switch from interbase
in the late 90's so all of the existing data can be maintained, and I
already have a working base on which to build a new set of page
templates. ( Only hole is the need for a decent javascript scheduler
function to replace the desktop one :( )

This is all running on SQL based schema's which have not changed in
years, and ADOdb still quite happily produces arrays of results for
which there is little point creating new 'objects', just simply handling
the basic variable entries in the arrays just as I have for years. The
various tools handle data validation, and 'null' is an essential
component of that validation process. This does not need any of the
overload of creating 'getters and setters' and I see little point trying
to add any 'type' casting into the process since the validation layer
simply works with the bog standard variables without and need for
'special cases'.

So what benefit does all of the additional 'facilities' now being piled
on give that would actually improve that process. I am now seeing a
speed improvement on the PHP7 ports, but I'm not seeing any point to
make any changes to code OTHER than making the PHP5.2 code clean on PHP7
... As Zeev has already said "PHP is not broken" ... Do I really need to
change the way I work which is running fine for my clients?

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

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

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

[Dominic Grostate]

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.

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

[Levi Morrison]

On Wed, Apr 20, 2016 at 11:55 AM, Jesse Schalken  wrote:
> I read the RFC and it all sounds good to me. I appreciate the care taken to
> ensure method compatibility rules are correct, a smooth interop with =null,
> and to consider impact on union types if added later (? just becomes sugar).
>
> I'm not sure if it's been mentioned or not, but the position of the ? has
> impact on the ability to add a foo[] shorthand for generic arrays. Namely,
> if the ? is at the start, then the syntax becomes ambiguous.
>
> string[]? (nullable array of strings)
>
> string?[] (array of nullable strings)
>
> ?string[] (ambiguous, need to consult precedence rules and/or use brackets)
>
>
> I'm not sure how HHVM/Hack deals with that, or if it even has the foo[]
> shorthand.

You would write `array`; Hack doesn't have a short-hand syntax.

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

Re: [PHP-DEV] Safe timeout handling

[Dmitry Stogov]

On 04/20/2016 08:40 PM, Bob Weinand wrote:


Am 20.04.2016 um 18:22 schrieb Dmitry Stogov >:




On 04/20/2016 06:24 PM, Matt Wilmas wrote:

Hi Dmitry,

- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, April 20, 2016


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.


I was thinking about this, checking for things like EG(exception) 
"constantly," a few months ago for another reason...


This is a bit different problem. We can't delay EG(exception) checks. 
I thought about a better way of exception handing but didn't find 
anything usable and portable.


What about instead of adding additional checks in the same place(s) 
in VM, we just limit it to 1 check, for multiple things? Just have 
EG(something_unexpected_to_check), and behind that (or in a 
function, I guess), the actual rare/unexpected thing gets checked: 
timed_out, exception, etc.


Yes, I have the same idea in background. I even wrote: The same 
"interrupt" handling mechanism in the future may be reused for TICK

and signal handling.



It seems Bob had a similar idea in the PR comment, except literally 
using exceptions...



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.


A single check would save those additional instructions and 
branches, and would actually improve things on Windows (since this 
PR doesn't change anything there).


If you or Bob show me a better working solution (or just PoC), I'll 
be only happy with this.


I looked at it; if we had an already existing if (EG(exception)) 
branch there, we could actually save something, but Dmitry put it just 
in jumping ops, where we never have an exception check. (And there we 
need a check as else a while(1) {} would never be timed out - i.e. 
when there are no ops inside which actually do a check_exception) … so 
this EG(something_unexpected_to_check) is even more expensive.
I meant later we may replace check for EG(timed_out) with check for 
EG(something_unexpected_to_check), and then perform additional checks in 
zend_vm_interrupt().


Thanks. Dmitry.



Things would be easy if we could just alter the return addresses of 
the opcode handlers or similar magic, but I doubt that's a very nice 
cross-platform solution...


If you have an even better idea than I do… please show a PoC :-)

Thanks,
Bob


Thanks. Dmitry.




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.


- Matt

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

[Jesse Schalken]

I read the RFC and it all sounds good to me. I appreciate the care taken to
ensure method compatibility rules are correct, a smooth interop with =null,
and to consider impact on union types if added later (? just becomes sugar).

I'm not sure if it's been mentioned or not, but the position of the ? has
impact on the ability to add a foo[] shorthand for generic arrays. Namely,
if the ? is at the start, then the syntax becomes ambiguous.

string[]? (nullable array of strings)

string?[] (array of nullable strings)

?string[] (ambiguous, need to consult precedence rules and/or use brackets)


I'm not sure how HHVM/Hack deals with that, or if it even has the foo[]
shorthand.


On Thu, Apr 14, 2016 at 1:42 PM, Levi Morrison 
wrote:

> As alluded to in an earlier email today[1] I am now moving the
> Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC
> proposes syntax for declaring a type to alternatively be null.
>
> There is a decision that needs to be made: does the question mark go
> before or after the type name?
>
> function (?Foo $foo);
> function (Foo? $foo);
>
> There are precedents in several languages for each position. Some
> relevant issues to where the question mark goes are noted in the
> RFC[3].
>
> I look forward to a helpful and meaningful discussion!
>
>   [1]: http://news.php.net/php.internals/92252
>   [2]: https://wiki.php.net/rfc/nullable_types
>   [3]: https://wiki.php.net/rfc/nullable_types#position_of
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[guilhermebla...@gmail.com]

PHP lacks of enterprise engineering over the language, and that is the
problem. You're not resolving the holism in the language, but rather a
specific part without consider the whole.

Yes, it makes sense to support ?Foo for and only for return types, but what
about everything else? What about future scope? Sure, future scope is
unknown, but we do have scope that is currently being defined, you're even
debating over it and it'll severely impacted by this small little support
that we're adopting right now only for this specific case.

The problem of not thinking in the language as a whole and just fixing
small bits every time lead to the inconsistency hell we live today. So
please, step back and look over that introducing this tiny language
enhancement will impact final properties, typed properties and add a
language inconsistency with already defined standard (instanced may be
absent of value like in function parameters). If you don't think what I'm
saying is true, look at return type hint and how you define parameter type
hint. And with typed properties (as the patch currently stands), it will
follow parameter type hint instead of return type hint.


Regards,

On Wed, Apr 20, 2016 at 12:13 PM, Dmitry Stogov  wrote:

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



-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Safe timeout handling

[Bob Weinand]

> Am 20.04.2016 um 18:22 schrieb Dmitry Stogov :
> 
> 
> 
> On 04/20/2016 06:24 PM, Matt Wilmas wrote:
>> Hi Dmitry,
>> 
>> - Original Message -
>> From: "Dmitry Stogov"
>> Sent: Wednesday, April 20, 2016
>> 
>>> 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.
>> 
>> I was thinking about this, checking for things like EG(exception) 
>> "constantly," a few months ago for another reason...
> 
> This is a bit different problem. We can't delay EG(exception) checks. I 
> thought about a better way of exception handing but didn't find anything 
> usable and portable.
>> 
>> What about instead of adding additional checks in the same place(s) in VM, 
>> we just limit it to 1 check, for multiple things? Just have 
>> EG(something_unexpected_to_check), and behind that (or in a function, I 
>> guess), the actual rare/unexpected thing gets checked: timed_out, exception, 
>> etc.
> 
> Yes, I have the same idea in background. I even wrote: The same "interrupt" 
> handling mechanism in the future may be reused for TICK
> and signal handling.
> 
>> 
>> It seems Bob had a similar idea in the PR comment, except literally using 
>> exceptions...
>> 
>>> 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.
>> 
>> A single check would save those additional instructions and branches, and 
>> would actually improve things on Windows (since this PR doesn't change 
>> anything there).
> 
> If you or Bob show me a better working solution (or just PoC), I'll be only 
> happy with this.

I looked at it; if we had an already existing if (EG(exception)) branch there, 
we could actually save something, but Dmitry put it just in jumping ops, where 
we never have an exception check. (And there we need a check as else a while(1) 
{} would never be timed out - i.e. when there are no ops inside which actually 
do a check_exception) … so this EG(something_unexpected_to_check) is even more 
expensive.

Things would be easy if we could just alter the return addresses of the opcode 
handlers or similar magic, but I doubt that's a very nice cross-platform 
solution...

If you have an even better idea than I do… please show a PoC :-)

Thanks,
Bob

> Thanks. Dmitry.
>> 
>> 
>>> 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.
>> 
>> - Matt

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

[Thomas Bley]

What do you think about default return values?

e.g.

function foo(): db_result = null {
}

function canLogin(): bool = false {
}

Regards
Thomas

Dmitry Stogov wrote on 20.04.2016 18:13:

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


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

Re: [PHP-DEV] Safe timeout handling

[Dmitry Stogov]

On 04/20/2016 06:24 PM, Matt Wilmas wrote:

Hi Dmitry,

- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, April 20, 2016


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.


I was thinking about this, checking for things like EG(exception) 
"constantly," a few months ago for another reason...


This is a bit different problem. We can't delay EG(exception) checks. I 
thought about a better way of exception handing but didn't find anything 
usable and portable.


What about instead of adding additional checks in the same place(s) in 
VM, we just limit it to 1 check, for multiple things? Just have 
EG(something_unexpected_to_check), and behind that (or in a function, 
I guess), the actual rare/unexpected thing gets checked: timed_out, 
exception, etc.


Yes, I have the same idea in background. I even wrote: The same 
"interrupt" handling mechanism in the future may be reused for TICK

and signal handling.



It seems Bob had a similar idea in the PR comment, except literally 
using exceptions...



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.


A single check would save those additional instructions and branches, 
and would actually improve things on Windows (since this PR doesn't 
change anything there).


If you or Bob show me a better working solution (or just PoC), I'll be 
only happy with this.


Thanks. Dmitry.




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.


- Matt



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

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

[Dmitry Stogov]

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:generics]

[Jesse Schalken]

Yes, if you have "class Box" and T is used for two
things, then "they must be of the same type, but they can be any same type
and that type must at least be Boxable". It means that Box can use a T as a
Boxable (call Boxable methods on it, etc).

On Thu, Apr 21, 2016 at 1:12 AM, Larry Garfield 
wrote:

> On 4/20/16 10:01 AM, Rowan Collins wrote:
>
>> guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
>>
>>> 1- Even though mentioned, I'd still use "extends" or "implements" instead
>>> of "is" (which would be a new pseudo-reserved keyword) to enforce data
>>> type
>>> consistency and prevent developers to potentially referring to one thing
>>> while consider another.
>>>
>>
>> Perhaps "instanceof" would make more sense here? "class FileProcessor> extends FileHandle>" seems to exclude instantiating
>> FileProcessor, because "FileHandle extends FileHandle" doesn't
>> make any sense.
>>
>> You could read "class Box" as an assertion that the
>> class passes the constraint, as in "public function __construct(T $t) {
>> assert($t instanceof Boxable); }"
>>
>> Regards,
>>
>
> I'm not an expert in generics by any means, but how is that different than
> just
>
> public function __construct(Boxable $t) {}
>
> I thought the point of generics was for cases like "these two variables
> must be the same type, but they can be any same type."
>
> --
> --Larry Garfield
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Dominic Grostate]

I agree on both points (technically).  It would allow you to apply that
restriction.  I only advise against it to reduce the impact the initial
implementation would have on the codebase, provided it is preferable to
implement it in phases.

As for inference. Rasmus and I have argued over that a fair bit, as I was
in favour of using 'new Entry<>' or just 'new Entry' to be a parameterised
type with no type constraints (any value).
On 20 Apr 2016 3:44 p.m., "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:

> I don't know if mid-thread answering may lead to top-posting, but if it
> does, I'm sorry... =\
>
> Answer inline:
>
> On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate <
> codekest...@googlemail.com> wrote:
>
>> I've made an amendment to the RFC to clarify on the Nested Types, which is
>> indeed supposed to be part of the feature.  Rasmus may want to reword it
>> if
>> it isn't very clear.
>>
>> Regarding union and intersections for upper (and maybe lower) bounds.
>> Would it be appropriate to exclude these from type parameters until their
>> respective RFCs are approved?  As including them in generics but not in
>> standard type hints may create an inconsistency.
>>
>> In short, perhaps a generics implementation should incorporate unions (and
>> any future type constraints) as existing features only.  This would help
>> RFC Generics to focus on: Type aliasing, Introspection and Reflection.
>>
>
> Unions and Intersections are required anyway, and I don't see how you can
> implement generics without supporting them.
> Let's say I'm implementing a cache library that segregate the interface of
> BulkOperations from the basic operations named CacheDriver.
> In a given class, I might want to only accept CacheDrivers that also
> support BulkOperations. How would I achieve that?
>
> The same happens to upper bounds that someone asked for an example
> privately.
> 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.
>
>
> Also, someone else asked about type inference over my comment #4 in this
> example:
>
> class Foo {
> public function __construct(B $b) {}
> }
>
> $foo = new Foo(1);
>
> The question asked is if that "string" was an inference over A or B. The
> correct answer is A, because generic type B is inferred from the parameter
> (integer) provided. That is exactly why class generic type definition
> should never be inferred from the constructor arguments, because you make
> it impossible to support both constructor generic types AND class generic
> type definitions at the same time.
>
>
>
>> On 20 Apr 2016 9:05 a.m., "Mathieu Rochette"  wrote:
>>
>> >
>> >
>> > On 20/04/2016 00:22, Sara Golemon wrote:
>> >
>> >> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette <
>> math...@texthtml.net>
>> >> wrote:
>> >>
>> >>> about the upper bounds, have you consider another way of describing
>> the
>> >>> constraints, eg:
>> >>>
>> >>> class Box where T is Boxable
>> >>>
>> >>> this would allow multiple constraints, eg:
>> >>>
>> >>> class Collection where T is Traversable, T is Countable
>> >>>
>> >>> IMO, this sort of problem should be solved by combining this feature
>> >> with union types, so you could have something like:
>> >>
>> >> class Collection {...
>> >>
>> >> And merely inherit the logic rules from that feature rather than
>> >> inventing yet another one.
>> >>
>> > obviously if the union type rfc passes we don't need another way of
>> > expressing this.
>> > that was only in the case it does not, I think having a way to have at
>> > least types intersection
>> > is useful here (and I didn't event think about )
>> >
>> >>
>> >> can generic types be nested ?
>> >>>
>> >>> class Stuff>
>> >>>
>> >>> I can't imagine why not...
>> >>
>> > just to be clear, it's not just nested generic. the A type have to be
>> same
>> > in both "subtypes"
>> >
>> >>
>> >> For my part, I love the concept overall.  Generics are an important
>> >> part of moving PHP towards comprehensive type-safety.  But then, you
>> >> know how 

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

[Rowan Collins]

guilhermebla...@gmail.com wrote on 20/04/2016 15:44:

In a given class, I might want to only accept CacheDrivers that also
support BulkOperations. How would I achieve that?


Apologies if this has been refuted elsewhere, but AFAIK you can 
implement any intersection constraint, albeit slightly more verbosely, 
by creating a new type:


- You can create a new interface that expresses an intersection of two 
other interfaces:


interface BulkOperationCacheDriver extends CacheDriver, BulkOperation {}

- Similarly, the intersection of a class and an interface can be created 
as an abstract class:


abstact class BulkRedisCacheDriver extends RedisCacheDriver implements 
BulkOperation {}


Since you can create those without modifying the underlying classes, you 
could specify generic constraints for any given intersection. A union 
constraint ("it can be either this or this") cannot currently be 
implemented, but the use cases are somewhat more questionable anyway.


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]

[Rowan Collins]

Larry Garfield wrote on 20/04/2016 16:12:

On 4/20/16 10:01 AM, Rowan Collins wrote:

guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
1- Even though mentioned, I'd still use "extends" or "implements" 
instead
of "is" (which would be a new pseudo-reserved keyword) to enforce 
data type
consistency and prevent developers to potentially referring to one 
thing

while consider another.


Perhaps "instanceof" would make more sense here? "class 
FileProcessor" seems to exclude instantiating 
FileProcessor, because "FileHandle extends FileHandle" 
doesn't make any sense.


You could read "class Box" as an assertion that 
the class passes the constraint, as in "public function __construct(T 
$t) { assert($t instanceof Boxable); }"


Regards,


I'm not an expert in generics by any means, but how is that different 
than just


public function __construct(Boxable $t) {}

I thought the point of generics was for cases like "these two 
variables must be the same type, but they can be any same type."




The is/extends/instanceof clause adds to the rule: "...they can be any 
same type, *as long as that type meets this constraint*"


So using an unbounded generic, you could manually check:

class FileProcessor
{
public function __construct(T $t) {
assert($t instanceof FileHandle);
}
}
$f = new FileProcessor($zip->getEntryHandle(1)); 
// "T" is substituted for "ZipArchiveEntryHandle"

$f = new FileProcessor(42); // assertion fails!


A bounded generic, using "is" as the keyword as in the current RFC, 
performs the assertion for you:


class FileProcessor
{
public function __construct(T $t) {
// no need for an assertion
}
}
$f = new FileProcessor(42); // throws a TypeError


My suggestion was that the constraint is like an "instanceof" assertion, 
so we could use that keyword:


class FileProcessor
{
public function __construct(T $t) {
// no need for an assertion
}
}
$f = new FileProcessor(42); // throws a TypeError


I hope that makes sense.

Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Safe timeout handling

[Matt Wilmas]

Hi Dmitry,

- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, April 20, 2016


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.


I was thinking about this, checking for things like EG(exception) 
"constantly," a few months ago for another reason...


What about instead of adding additional checks in the same place(s) in VM, 
we just limit it to 1 check, for multiple things?  Just have 
EG(something_unexpected_to_check), and behind that (or in a function, I 
guess), the actual rare/unexpected thing gets checked: timed_out, exception, 
etc.


It seems Bob had a similar idea in the PR comment, except literally using 
exceptions...



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.


A single check would save those additional instructions and branches, and 
would actually improve things on Windows (since this PR doesn't change 
anything there).



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.


- Matt 



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

Re: [PHP-DEV] writing .phpt tests against IS_INDIRECT values

[Nikita Popov]

On Wed, Apr 20, 2016 at 5:08 PM, Adam Baratz  wrote:

> I'm contributing to an extension --
> https://github.com/jbboehr/php-mustache
> -- and part of that has been little fixes for PHP7. I posted a PR to fix
> how it was handling zvals that came in as IS_INDIRECT. The maintainer asked
> if I could extend the .phpt coverage accordingly. The reading I've done has
> made it sound like this is an implementation detail that would never
> surface in userland. Is that true, or is there something I can do from
> tests to make sure these code paths get used?
>

Assuming you're talking about hashtables here and not engine code, there
are two places where INDIRECT values are used:
a) The object properties hashtable (if used) contains INDIRECT references
to declared properties in the property table.
b) The $GLOBALS array contains INDIRECT references to variables in the CV
table.

That's the only two cases how you should be able to encounter INDIRECTs in
"normal" extension code. (I think.)

Nikita

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

[guilhermebla...@gmail.com]

Sure, the usage of "instanceof" is an alternative to prevent declaring a
new keyword. PHP doesn't have the same problem as Java does to enforce the
first generic type information to be a class and others interfaces. So in
this:

class A {}
interface B {}
interface C {}

class Foo {}

Java required A to be the first due to its compilation process, which PHP
does not have. PHP would accept any order of A, B and C there, like "C & B
".


PS: I like to use Java as a base for Generics because I feel it more well
thought than other language implementations (like .NET and Swift).

Regards,

On Wed, Apr 20, 2016 at 11:01 AM, Rowan Collins 
wrote:

> guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
>
>> 1- Even though mentioned, I'd still use "extends" or "implements" instead
>> of "is" (which would be a new pseudo-reserved keyword) to enforce data
>> type
>> consistency and prevent developers to potentially referring to one thing
>> while consider another.
>>
>
> Perhaps "instanceof" would make more sense here? "class FileProcessor extends FileHandle>" seems to exclude instantiating
> FileProcessor, because "FileHandle extends FileHandle" doesn't
> make any sense.
>
> You could read "class Box" as an assertion that the
> class passes the constraint, as in "public function __construct(T $t) {
> assert($t instanceof Boxable); }"
>
> 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]

[Larry Garfield]

On 4/20/16 10:01 AM, Rowan Collins wrote:

guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
1- Even though mentioned, I'd still use "extends" or "implements" 
instead
of "is" (which would be a new pseudo-reserved keyword) to enforce 
data type

consistency and prevent developers to potentially referring to one thing
while consider another.


Perhaps "instanceof" would make more sense here? "class 
FileProcessor" seems to exclude instantiating 
FileProcessor, because "FileHandle extends FileHandle" 
doesn't make any sense.


You could read "class Box" as an assertion that 
the class passes the constraint, as in "public function __construct(T 
$t) { assert($t instanceof Boxable); }"


Regards,


I'm not an expert in generics by any means, but how is that different 
than just


public function __construct(Boxable $t) {}

I thought the point of generics was for cases like "these two variables 
must be the same type, but they can be any same type."


--
--Larry Garfield


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

[PHP-DEV] writing .phpt tests against IS_INDIRECT values

[Adam Baratz]

I'm contributing to an extension -- https://github.com/jbboehr/php-mustache
-- and part of that has been little fixes for PHP7. I posted a PR to fix
how it was handling zvals that came in as IS_INDIRECT. The maintainer asked
if I could extend the .phpt coverage accordingly. The reading I've done has
made it sound like this is an implementation detail that would never
surface in userland. Is that true, or is there something I can do from
tests to make sure these code paths get used?

Thanks,
Adam

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

[guilhermebla...@gmail.com]

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:generics]

[Rowan Collins]

guilhermebla...@gmail.com wrote on 20/04/2016 03:54:

1- Even though mentioned, I'd still use "extends" or "implements" instead
of "is" (which would be a new pseudo-reserved keyword) to enforce data type
consistency and prevent developers to potentially referring to one thing
while consider another.


Perhaps "instanceof" would make more sense here? "class FileProcessorextends FileHandle>" seems to exclude instantiating 
FileProcessor, because "FileHandle extends FileHandle" 
doesn't make any sense.


You could read "class Box" as an assertion that 
the class passes the constraint, as in "public function __construct(T 
$t) { assert($t instanceof Boxable); }"


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]

[guilhermebla...@gmail.com]

I don't know if mid-thread answering may lead to top-posting, but if it
does, I'm sorry... =\

Answer inline:

On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate <
codekest...@googlemail.com> wrote:

> I've made an amendment to the RFC to clarify on the Nested Types, which is
> indeed supposed to be part of the feature.  Rasmus may want to reword it if
> it isn't very clear.
>
> Regarding union and intersections for upper (and maybe lower) bounds.
> Would it be appropriate to exclude these from type parameters until their
> respective RFCs are approved?  As including them in generics but not in
> standard type hints may create an inconsistency.
>
> In short, perhaps a generics implementation should incorporate unions (and
> any future type constraints) as existing features only.  This would help
> RFC Generics to focus on: Type aliasing, Introspection and Reflection.
>

Unions and Intersections are required anyway, and I don't see how you can
implement generics without supporting them.
Let's say I'm implementing a cache library that segregate the interface of
BulkOperations from the basic operations named CacheDriver.
In a given class, I might want to only accept CacheDrivers that also
support BulkOperations. How would I achieve that?

The same happens to upper bounds that someone asked for an example
privately.
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.


Also, someone else asked about type inference over my comment #4 in this
example:

class Foo {
public function __construct(B $b) {}
}

$foo = new Foo(1);

The question asked is if that "string" was an inference over A or B. The
correct answer is A, because generic type B is inferred from the parameter
(integer) provided. That is exactly why class generic type definition
should never be inferred from the constructor arguments, because you make
it impossible to support both constructor generic types AND class generic
type definitions at the same time.



> On 20 Apr 2016 9:05 a.m., "Mathieu Rochette"  wrote:
>
> >
> >
> > On 20/04/2016 00:22, Sara Golemon wrote:
> >
> >> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette  >
> >> wrote:
> >>
> >>> about the upper bounds, have you consider another way of describing the
> >>> constraints, eg:
> >>>
> >>> class Box where T is Boxable
> >>>
> >>> this would allow multiple constraints, eg:
> >>>
> >>> class Collection where T is Traversable, T is Countable
> >>>
> >>> IMO, this sort of problem should be solved by combining this feature
> >> with union types, so you could have something like:
> >>
> >> class Collection {...
> >>
> >> And merely inherit the logic rules from that feature rather than
> >> inventing yet another one.
> >>
> > obviously if the union type rfc passes we don't need another way of
> > expressing this.
> > that was only in the case it does not, I think having a way to have at
> > least types intersection
> > is useful here (and I didn't event think about )
> >
> >>
> >> can generic types be nested ?
> >>>
> >>> class Stuff>
> >>>
> >>> I can't imagine why not...
> >>
> > just to be clear, it's not just nested generic. the A type have to be
> same
> > in both "subtypes"
> >
> >>
> >> For my part, I love the concept overall.  Generics are an important
> >> part of moving PHP towards comprehensive type-safety.  But then, you
> >> know how I feel about Hack. :)
> >>
> >> -Sara
> >>
> >>
> >
>



-- 
Guilherme Blanco
Lead Architect at E-Block

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

[Zeev Suraski]

From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On Behalf Of 
Jesse Schalken
Sent: Wednesday, April 20, 2016 4:42 PM
To: Zeev Suraski 
Cc: PHP internals 
Subject: Re: [PHP-DEV] Re: Improving PHP's type system



On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski 
> wrote:

On 20 באפר׳ 2016, at 14:54, Jesse Schalken 
> wrote:
If I had "scalar", "number" and ?T as types, the types I would need would be:

  1.  ?scalar|Decimal

What's decimal?  I'm not aware we have that type.  Apologies if I missed it 
that it was added.

As I said:

I have a function that converts values to SQL which have SQL equivalents, 
including decimal values represented by a special Decimal class. It accepts 
int|string|bool|null|float|Decimal.

Zeev> So just use a container class (SQLValue or whatnot) that can include a 
scalar or a Decimal, and use this instead.  It would probably result in a 
cleaner function body anyway.


  1.  ?scalar|Decimal|Expr

What's Expr?  Again I'm not aware that we have that type.

As I said:

I have a class Expr which represents an expression in SQL. Expressions can be 
composed of other expressions, and of literal values, so the constructors for 
Exprs accept int|string|bool|null|float|Decimal|Expr.

Zeev> Same as above.  Another option of course is to handle the type checks 
inside – that depends on whether you want to handle the details inside the 
SQLValue class or inside the function that accepts it.


  1.  ?scalar|array
Conduct this check in user code, you'd have to anyway.

Not if I'm giving it straight to json_encode() I don't.

Zeev> Why not let json_encode() do the type checking then?

  1.  int|string (I want int|string here. I know array keys are always 
int|string. A wider type is lies.)
This is needlessly purist.  For handling a meaningless con, we'd overcomplicate 
the language and provide a footgun(tm) for everyone.  Not a good bargain.

int|string is the correct type. If you're going to dismiss correctness as 
"needlessly purist" then I'm going to dismiss PHP as not intended for writing 
correct software.

Zeev> Purism by definition – in all areas of life - insists it’s the one and 
only correct way to look at things.  PHP has never been about purism, and we’re 
not going to start now.  Instead of adjusting to how PHP models scalars, or 
moving to another language (both very valid options) – you insist on saying PHP 
must change to be your way.

  1.  T|false
You didn't answer my question on this one.

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.

Zeev> Why is it important to have a type that maps the return values of these 
functions?  What does it buy you?

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

[Jesse Schalken]

On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski  wrote:

>
> On 20 באפר׳ 2016, at 14:54, Jesse Schalken  wrote:
>
> If I had "scalar", "number" and ?T as types, the types I would need would
> be:
>
>1. ?scalar|Decimal
>
>
> What's decimal?  I'm not aware we have that type.  Apologies if I missed
> it that it was added.
>

As I said:

I have a function that converts values to SQL which have SQL equivalents,
> including decimal values represented by a special Decimal class. It accepts
> int|string|bool|null|float|Decimal.


All of int|string|bool|null|float can be converted to SQL
straightforwardly, however, MySQL has a distinct decimal type for exact
decimal values, written like "8542.31" in SQL (to get write a float, you
need "8542.31e0"). My class Decimal is used to represent a MySQL value of
type decimal, so it can be passed without be lossily converted to/from
float, and so it can be converted to the correct SQL. It is neither a float
nor an integer. A distinct class is needed for it.

>
>1. ?scalar|Decimal|Expr
>
>
> What's Expr?  Again I'm not aware that we have that type.
>

As I said:

I have a class Expr which represents an expression in SQL. Expressions can
> be composed of other expressions, and of literal values, so the
> constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.



In both, a nullable scalar does the job.
>
>
>1. ?scalar|array
>
> Conduct this check in user code, you'd have to anyway.
>

Not if I'm giving it straight to json_encode() I don't.


>
>1. int|string (I *want* int|string here. I know array keys are always
>int|string. A wider type is lies.)
>
> This is needlessly purist.  For handling a meaningless con, we'd
> overcomplicate the language and provide a footgun(tm) for everyone.  Not a
> good bargain.
>

int|string is the correct type. If you're going to dismiss correctness as
"needlessly purist" then I'm going to dismiss PHP as not intended for
writing correct software.

>
>1. ?scalar (probably)
>
> Ok
>
>
>1. number
>
> Ok
>
>
>1. T|false
>
> You didn't answer my question on this one.
>

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.


>1. ?T
>
> Ok
>
> 5 out of 8 still need a union.
>
>
> Actually, in my count only one of them does (#7) and it's probably
> solvable (if it's even a thing), and in another, it makes no sense to use
> types at all (#3) as you'd have to do these checks in userland anyway.  All
> others can be satisfied just fine with scalar, numeric and nullable types,
> unless you're being needlessly purist - and we're not going to
> overcomplicate the language for the sake of purism.
>
> Zeev
>

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

[Zeev Suraski]

> -Original Message-
> From: Tom Worster [mailto:f...@thefsb.org]
> Sent: Wednesday, April 20, 2016 4:24 PM
> To: Rick Widmer ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> On 4/19/16 7:21 PM, Rick Widmer wrote:
> > Are too many of these incompatible shiny things, too fast, the main
> > reason so many PHP users are on older versions?
> >
> > IMHO, yes.
> 
> This would mean, by an large, that people had tried a more recent version of
> PHP and found that their code was incompatible. I think on the contrary that
> they haven't tried because they have little motive. A lot of running apps are 
> in
> maintenance mode with no significant investments in new code, without
> which it's easier to take the attitude that it's not broken so don't mess 
> around
> with it.

It's more complicated than that - people don't actually have to try and upgrade 
in order to know (or think they know) that they'll have to invest time and 
efforts in getting their code to run on a new version.  They guess as much.

That said, I don't think the issue with shiny new things is that they introduce 
incompatibilities.  They rarely do - I think the biggest source of 
incompatibilities we have is removal of deprecated features and not 
introduction of new ones.  Shiny new features have other issues - increased 
cognitive burden, increased code complexity, etc. - but typically introduction 
of incompatibilities is not one of them.

However, we can learn that the attractiveness of new features in PHP is not 
very high - or we'd see much faster adoption of new versions (which also leads 
me to believe that we're spending too much effort on the wrong things).  I 
think we're going to see much faster adoption of 7.0 - but in my experience at 
least, it's predominantly the increased performance and reduced memory 
consumption that gets people excited - the new features are secondary if they 
play any role at the decision.

Zeev

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

[Tom Worster]

On 4/19/16 7:21 PM, Rick Widmer wrote:

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

IMHO, yes.


This would mean, by an large, that people had tried a more recent 
version of PHP and found that their code was incompatible. I think on 
the contrary that they haven't tried because they have little motive. A 
lot of running apps are in maintenance mode with no significant 
investments in new code, without which it's easier to take the attitude 
that it's not broken so don't mess around with it.


Tom


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

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

[Zeev Suraski]

On 20 ? 2016, at 14:54, Jesse Schalken 
> wrote:

If I had "scalar", "number" and ?T as types, the types I would need would be:

  1.  ?scalar|Decimal

What's decimal?  I'm not aware we have that type.  Apologies if I missed it 
that it was added.

  1.  ?scalar|Decimal|Expr

What's Expr?  Again I'm not aware that we have that type.

In both, a nullable scalar does the job.

  1.  ?scalar|array

Conduct this check in user code, you'd have to anyway.

  1.  int|string (I want int|string here. I know array keys are always 
int|string. A wider type is lies.)

This is needlessly purist.  For handling a meaningless con, we'd overcomplicate 
the language and provide a footgun(tm) for everyone.  Not a good bargain.

  1.  ?scalar (probably)

Ok

  1.  number

Ok

  1.  T|false

You didn't answer my question on this one.

  1.  ?T

Ok

5 out of 8 still need a union.

Actually, in my count only one of them does (#7) and it's probably solvable (if 
it's even a thing), and in another, it makes no sense to use types at all (#3) 
as you'd have to do these checks in userland anyway.  All others can be 
satisfied just fine with scalar, numeric and nullable types, unless you're 
being needlessly purist - and we're not going to overcomplicate the language 
for the sake of purism.

Zeev

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-04-20

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-20 06:28:37+03:00
commit: 23a4342
previous commit:60b1441
revision date:  2016-04-18 23:34:44-07: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.27%  0.15%  0.85%  
  7.35%
:-|   Drupal 7.36 cgi -T1  0.13%  0.29%  0.22%  
  4.43%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16%  0.09%  1.62%  
  3.54%
:-)   bench.php cgi -T100  0.00%  2.13% 25.39%  
  1.74%
:-|  micro_bench.php cgi -T10  0.00%  0.36%  6.21%  
  3.65%
:-|  mandelbrot.php cgi -T100  0.02%  0.10% 28.98%  
  6.20%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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

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

[Jesse Schalken]

I just noticed I originally missed "array" for #3. (The type is technically
recursive, ie "type Jsonable = int|string|float|bool|null|array",
but that's another can of worms.)

On Wed, Apr 20, 2016 at 9:54 PM, Jesse Schalken 
wrote:

> If I had "scalar", "number" and ?T as types, the types I would need would
> be:
>
>1. ?scalar|Decimal
>2. ?scalar|Decimal|Expr
>3. ?scalar|array
>4. int|string (I *want* int|string here. I know array keys are always
>int|string. A wider type is lies.)
>5. ?scalar (probably)
>6. number
>7. T|false
>8. ?T
>
> 5 out of 8 still need a union.
>
> On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski  wrote:
>
>>
>>
>> > -Original Message-
>> > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
>> > Behalf Of Jesse Schalken
>> > Sent: Wednesday, April 20, 2016 1:12 PM
>> > To: Johannes Schlüter 
>> > Cc: Andrea Faulds ; PHP internals 
>> > Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>> >
>> >1. I have a function that converts values to SQL which have SQL
>> >equivalents, including decimal values represented by a special
>> Decimal
>> >class. It accepts int|string|bool|null|float|Decimal.
>> >2. I have a class Expr which represents an expression in SQL.
>> >Expressions can be composed of other expressions, and of literal
>> values, so
>> >the constructors for Exprs accept
>> int|string|bool|null|float|Decimal|Expr.
>> >3. I have a function that converts values to JSON that can be
>> reliably
>> >converted back into their original. It accepts
>> int|string|bool|null|float.
>>
>> In other words, they accepts scalars (or nullable scalars).  Introducing
>> a scalar type would do the job.
>>
>> >4. I have a function that returns the first key in an array (or
>> throws
>> >an exception if empty). It returns int|string.
>>
>> I'd argue that here too, a scalar would be fine.  Worrying about a
>> floating point here is not a very relevant worry.
>>
>> >5. I have a function that returns a value for a key in an array, and
>> >removes the key. The type of the key is things that are valid array
>> keys
>> >(int|string|bool|null IIRC).
>>
>> Scalar (or nullable scalar).
>>
>> >6. I have a set of functions which operates on numbers. They accept
>> >int|float.
>>
>> Numeric (to also include strings that look like numbers when strict is
>> not on).
>>
>> >7. All the PHP functions which say "returns ... or FALSE on failure"
>> >have their correct return type as T|false (where T is the return
>> value on
>> >success) (or T|bool is "false" is not an allowed type).
>>
>> How many of those do we have?  As opposed to T|null?  I think most
>> functions that return objects return null on failure, not false.  And those
>> who don't can probably evolve to that approach.
>>
>> >8. Nullability is nothing but a special case of union type with
>> T|null.
>>
>> Academically that's true, but practically speaking, the general T1|T2 is
>> almost always bogus while T|null subset makes a lot of sense.
>>
>> In reality, we can solve all the relevant use cases for union types by
>> relatively minor tweaks (or rather additions) to our scalar type hints, by
>> adding nullability, and by using interfaces where they make sense.
>>
>> Zeev
>>
>
>

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

[Jesse Schalken]

If I had "scalar", "number" and ?T as types, the types I would need would
be:

   1. ?scalar|Decimal
   2. ?scalar|Decimal|Expr
   3. ?scalar|array
   4. int|string (I *want* int|string here. I know array keys are always
   int|string. A wider type is lies.)
   5. ?scalar (probably)
   6. number
   7. T|false
   8. ?T

5 out of 8 still need a union.

On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
> > Behalf Of Jesse Schalken
> > Sent: Wednesday, April 20, 2016 1:12 PM
> > To: Johannes Schlüter 
> > Cc: Andrea Faulds ; PHP internals 
> > Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> >
> >1. I have a function that converts values to SQL which have SQL
> >equivalents, including decimal values represented by a special Decimal
> >class. It accepts int|string|bool|null|float|Decimal.
> >2. I have a class Expr which represents an expression in SQL.
> >Expressions can be composed of other expressions, and of literal
> values, so
> >the constructors for Exprs accept
> int|string|bool|null|float|Decimal|Expr.
> >3. I have a function that converts values to JSON that can be reliably
> >converted back into their original. It accepts
> int|string|bool|null|float.
>
> In other words, they accepts scalars (or nullable scalars).  Introducing a
> scalar type would do the job.
>
> >4. I have a function that returns the first key in an array (or throws
> >an exception if empty). It returns int|string.
>
> I'd argue that here too, a scalar would be fine.  Worrying about a
> floating point here is not a very relevant worry.
>
> >5. I have a function that returns a value for a key in an array, and
> >removes the key. The type of the key is things that are valid array
> keys
> >(int|string|bool|null IIRC).
>
> Scalar (or nullable scalar).
>
> >6. I have a set of functions which operates on numbers. They accept
> >int|float.
>
> Numeric (to also include strings that look like numbers when strict is not
> on).
>
> >7. All the PHP functions which say "returns ... or FALSE on failure"
> >have their correct return type as T|false (where T is the return
> value on
> >success) (or T|bool is "false" is not an allowed type).
>
> How many of those do we have?  As opposed to T|null?  I think most
> functions that return objects return null on failure, not false.  And those
> who don't can probably evolve to that approach.
>
> >8. Nullability is nothing but a special case of union type with
> T|null.
>
> Academically that's true, but practically speaking, the general T1|T2 is
> almost always bogus while T|null subset makes a lot of sense.
>
> In reality, we can solve all the relevant use cases for union types by
> relatively minor tweaks (or rather additions) to our scalar type hints, by
> adding nullability, and by using interfaces where they make sense.
>
> Zeev
>

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

[Zeev Suraski]

> -Original Message-
> From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
> Behalf Of Jesse Schalken
> Sent: Wednesday, April 20, 2016 1:12 PM
> To: Johannes Schlüter 
> Cc: Andrea Faulds ; PHP internals 
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
>1. I have a function that converts values to SQL which have SQL
>equivalents, including decimal values represented by a special Decimal
>class. It accepts int|string|bool|null|float|Decimal.
>2. I have a class Expr which represents an expression in SQL.
>Expressions can be composed of other expressions, and of literal values, so
>the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.
>3. I have a function that converts values to JSON that can be reliably
>converted back into their original. It accepts int|string|bool|null|float.

In other words, they accepts scalars (or nullable scalars).  Introducing a 
scalar type would do the job.

>4. I have a function that returns the first key in an array (or throws
>an exception if empty). It returns int|string.

I'd argue that here too, a scalar would be fine.  Worrying about a floating 
point here is not a very relevant worry.

>5. I have a function that returns a value for a key in an array, and
>removes the key. The type of the key is things that are valid array keys
>(int|string|bool|null IIRC).

Scalar (or nullable scalar).

>6. I have a set of functions which operates on numbers. They accept
>int|float.

Numeric (to also include strings that look like numbers when strict is not on).

>7. All the PHP functions which say "returns ... or FALSE on failure"
>have their correct return type as T|false (where T is the return value on
>success) (or T|bool is "false" is not an allowed type).

How many of those do we have?  As opposed to T|null?  I think most functions 
that return objects return null on failure, not false.  And those who don't can 
probably evolve to that approach.

>8. Nullability is nothing but a special case of union type with T|null.

Academically that's true, but practically speaking, the general T1|T2 is almost 
always bogus while T|null subset makes a lot of sense.

In reality, we can solve all the relevant use cases for union types by 
relatively minor tweaks (or rather additions) to our scalar type hints, by 
adding nullability, and by using interfaces where they make sense.

Zeev

[PHP-DEV] Safe timeout handling

[Dmitry Stogov]

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.

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

[S.A.N]

2016-04-19 19:54 GMT+03:00 David Zuelke :
> I think this solution is merely a band-aid for a more profound architectural 
> weakness of current PHP setups, where a web server call out to the engine 
> (via embedding or FastCGI) to execute a script, which causes this recurring 
> initialization overhead in the first place.
>
> The future is (or should be) servers implemented fully in PHP code (e.g. 
> PHP-PM), just like every other comparable language (Ruby, Python, Java, ...) 
> already does. That also brings many other benefits, such as the ability to 
> handle upgrades to WebSockets in the same codebase, stream request bodies as 
> they're being uploaded, and so forth.
>
> And the performance figures that PHP-PM delivers with Symfony validate that 
> approach IMO.
>

I agree, and developers are already discussing a common event-loop API:
https://github.com/async-interop/event-loop

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

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

[Jesse Schalken]

   1. I have a function that converts values to SQL which have SQL
   equivalents, including decimal values represented by a special Decimal
   class. It accepts int|string|bool|null|float|Decimal.
   2. I have a class Expr which represents an expression in SQL.
   Expressions can be composed of other expressions, and of literal values, so
   the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.
   3. I have a function that converts values to JSON that can be reliably
   converted back into their original. It accepts int|string|bool|null|float.
   4. I have a function that returns the first key in an array (or throws
   an exception if empty). It returns int|string.
   5. I have a function that returns a value for a key in an array, and
   removes the key. The type of the key is things that are valid array keys
   (int|string|bool|null IIRC).
   6. I have a set of functions which operates on numbers. They accept
   int|float.
   7. All the PHP functions which say "returns ... or FALSE on failure"
   have their correct return type as T|false (where T is the return value on
   success) (or T|bool is "false" is not an allowed type).
   8. Nullability is nothing but a special case of union type with T|null.

If you need more examples, search some PHP codebases for PHPDoc blocks with
union types with a regex, like "@(param|var)\s*(\$\w+\s*)?\w+\|".


On Wed, Apr 20, 2016 at 7:46 PM, Johannes Schlüter 
wrote:

> On Wed, 2016-04-20 at 17:57 +1000, Jesse Schalken wrote:
> >
> > With unions:
> >
> > function foo(Bar|string $b) {
> >
> > if (is_string($b)) {
> > // ...
> > } else {
> > // I know $b is a Bar here. I don't need to check. :)
> > }
> > }
>
> I' still missing a real-life use case for this. There's no operation I
> can come up with which works with an object or string.
>
> Unions between object types should be handled via interface.
>
> The only relevant union types I found till now are
>
>   array | Traversable
>   array | Countable
>
> and eventually
>
>   array | Offset[Get|Set]
>
> The last one is a bit critical due to the fact that arrays are value
> types, whereas objects are reference types so
>
>function ($a) {
>$a[] = 42;
>}
>
> behaves notably differently between objects and arrays. So that case
> might need some thinking. For the others instead of a generic union type
> I'd prefer a special array-solution.
>
> johannes
>

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

[Johannes Schlüter]

On Wed, 2016-04-20 at 18:32 +1000, Jesse Schalken wrote:
> On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An 
> wrote:
> 
> >
> > I think the original purpose of adding type system in Hack, is to provide
> > just-in-time compilation, this provides more information to let compiler to
> > optimize the code with specific type.
> >
> >
> Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
> and doesn't use the Hack type annotations for any optimisation. It's is
> really just another dynamic language JIT, like V8 and Chakra.
> 
> The purpose of type annotations and type checkers for dynamic languages,
> including Hack, TypeScript and Flow, is not necessarily to improve
> performance but to improve developer efficiency. Wherever there exists a
> type annotation which is enforced, either statically or at runtime, the
> developer has gained important knowledge to inform the modification of the
> program, and can do so with increased certainty and predictability.

For that there is some research:

How many bugs does static type checking catch?
[...]
answer: 2%.
[...]
not only were development times significantly shorter on average
with dynamically typed languages, so were debug times.

So all those nasty type errors were actually not having any
negative impact on debug times, in fact the reverse was true.

http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html

johannes


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

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

[Johannes Schlüter]

On Wed, 2016-04-20 at 17:57 +1000, Jesse Schalken wrote:
> 
> With unions:
> 
> function foo(Bar|string $b) {
> 
> if (is_string($b)) {
> // ...
> } else {
> // I know $b is a Bar here. I don't need to check. :)
> }
> }

I' still missing a real-life use case for this. There's no operation I
can come up with which works with an object or string.

Unions between object types should be handled via interface.

The only relevant union types I found till now are

  array | Traversable
  array | Countable

and eventually

  array | Offset[Get|Set]

The last one is a bit critical due to the fact that arrays are value
types, whereas objects are reference types so

   function ($a) {
   $a[] = 42;
   }

behaves notably differently between objects and arrays. So that case
might need some thinking. For the others instead of a generic union type
I'd prefer a special array-solution.

johannes


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

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

[Quim Calpe]

On Wed, Apr 20, 2016 at 11:10 AM, Dominic Grostate <
codekest...@googlemail.com> wrote:

> I've made an amendment to the RFC to clarify on the Nested Types, which is
> indeed supposed to be part of the feature.  Rasmus may want to reword it if
> it isn't very clear.
>
> Regarding union and intersections for upper (and maybe lower) bounds.
> Would it be appropriate to exclude these from type parameters until their
> respective RFCs are approved?  As including them in generics but not in
> standard type hints may create an inconsistency.
>
> In short, perhaps a generics implementation should incorporate unions (and
> any future type constraints) as existing features only.  This would help
> RFC Generics to focus on: Type aliasing, Introspection and Reflection.
>

That would be a wise move, there are currently some RFCs with similar areas
of contention


> On 20 Apr 2016 9:05 a.m., "Mathieu Rochette"  wrote:
>
> >
> >
> > On 20/04/2016 00:22, Sara Golemon wrote:
> >
> >> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette  >
> >> wrote:
> >>
> >>> about the upper bounds, have you consider another way of describing the
> >>> constraints, eg:
> >>>
> >>> class Box where T is Boxable
> >>>
> >>> this would allow multiple constraints, eg:
> >>>
> >>> class Collection where T is Traversable, T is Countable
> >>>
> >>> IMO, this sort of problem should be solved by combining this feature
> >> with union types, so you could have something like:
> >>
> >> class Collection {...
> >>
> >> And merely inherit the logic rules from that feature rather than
> >> inventing yet another one.
> >>
> > obviously if the union type rfc passes we don't need another way of
> > expressing this.
> > that was only in the case it does not, I think having a way to have at
> > least types intersection
> > is useful here (and I didn't event think about )
> >
> >>
> >> can generic types be nested ?
> >>>
> >>> class Stuff>
> >>>
> >>> I can't imagine why not...
> >>
> > just to be clear, it's not just nested generic. the A type have to be
> same
> > in both "subtypes"
> >
> >>
> >> For my part, I love the concept overall.  Generics are an important
> >> part of moving PHP towards comprehensive type-safety.  But then, you
> >> know how I feel about Hack. :)
> >>
> >> -Sara
> >>
> >>
> >
>

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

[Dominic Grostate]

I've made an amendment to the RFC to clarify on the Nested Types, which is
indeed supposed to be part of the feature.  Rasmus may want to reword it if
it isn't very clear.

Regarding union and intersections for upper (and maybe lower) bounds.
Would it be appropriate to exclude these from type parameters until their
respective RFCs are approved?  As including them in generics but not in
standard type hints may create an inconsistency.

In short, perhaps a generics implementation should incorporate unions (and
any future type constraints) as existing features only.  This would help
RFC Generics to focus on: Type aliasing, Introspection and Reflection.
On 20 Apr 2016 9:05 a.m., "Mathieu Rochette"  wrote:

>
>
> On 20/04/2016 00:22, Sara Golemon wrote:
>
>> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette 
>> wrote:
>>
>>> about the upper bounds, have you consider another way of describing the
>>> constraints, eg:
>>>
>>> class Box where T is Boxable
>>>
>>> this would allow multiple constraints, eg:
>>>
>>> class Collection where T is Traversable, T is Countable
>>>
>>> IMO, this sort of problem should be solved by combining this feature
>> with union types, so you could have something like:
>>
>> class Collection {...
>>
>> And merely inherit the logic rules from that feature rather than
>> inventing yet another one.
>>
> obviously if the union type rfc passes we don't need another way of
> expressing this.
> that was only in the case it does not, I think having a way to have at
> least types intersection
> is useful here (and I didn't event think about )
>
>>
>> can generic types be nested ?
>>>
>>> class Stuff>
>>>
>>> I can't imagine why not...
>>
> just to be clear, it's not just nested generic. the A type have to be same
> in both "subtypes"
>
>>
>> For my part, I love the concept overall.  Generics are an important
>> part of moving PHP towards comprehensive type-safety.  But then, you
>> know how I feel about Hack. :)
>>
>> -Sara
>>
>>
>

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

[Lester Caine]

On 20/04/16 00:34, Johannes Schlüter wrote:
> On Wed, 2016-04-20 at 00:09 +0200, Marco Pivetta wrote:
>> > In Doctrine ORM, having a way to know that a field or parameter is a
>> > `string | null` or a `int | float` may be the difference between
>> > knowing
>> > what kind of column definition is needed for a field at DB level,
>> > without
>> > even need for defining manual mappings.
> So what's the column definition if you see `string | null`? A PHP string
> can have (almost) arbitrary length and binary data, so this is a BLOB?
> Most likely not what the user wants. 
> 
> The PHP type hardly describes the constraints by the application. This
> might add a small sanity check but by no means a game changer.

String length, size of integer and accuracy of numeric all affect the
definition of the schema at the DB level which adding a little twiddly
bit does nothing to provide an expandable type definition. I'm not
objecting to a type system per-say but even the bits that have been
bodged into PHP7 already do not provide a route forward for REAL data
validation?

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

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

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

[Jesse Schalken]

On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An 
wrote:

>
> I think the original purpose of adding type system in Hack, is to provide
> just-in-time compilation, this provides more information to let compiler to
> optimize the code with specific type.
>
>
Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
and doesn't use the Hack type annotations for any optimisation. It's is
really just another dynamic language JIT, like V8 and Chakra.

The purpose of type annotations and type checkers for dynamic languages,
including Hack, TypeScript and Flow, is not necessarily to improve
performance but to improve developer efficiency. Wherever there exists a
type annotation which is enforced, either statically or at runtime, the
developer has gained important knowledge to inform the modification of the
program, and can do so with increased certainty and predictability.

[PHP-DEV] PHP 5.6.21 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.21 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.21RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for April 28th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.21RC1.tar.bz2
SHA256 hash:
098cbd59b9c1a67154038dc3641497581afb85966c9599c84e8acd4cfa040fb0
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzo/AAoJEMK/C8Qzz8izX3AIAJkoZLwqeRXp4zVGQMRqo4dm
UFWYJFPS8iwfzagVQu004NSn8KpjIfTn7S5W+htPH9/wjG44otch3VwcIA7oeCmR
/8yqG904BGSe8bv6VzzOcostofKs29t0J8Mvne1JQIBZaXZb+zRGUK5K2w/M1FWa
uM1tao1gADphqzETaW9HY3fPJokORWSKdisHt2/bGY7iFJplAaN29s7zoZsLyFdJ
rsByAoBF97C6NTNcMavQJ2odvWwBahfLKcBTT6bNAYq//aLwRUtH0l8jjstHxUkx
ctkAVo/pjIJ4jrDa2yhJyMAZN+sfqjmCpcMgvuR+KlA3uGK6f1vrwAPWUgU2+bw=
=tPtO
-END PGP SIGNATURE-

php-5.6.21RC1.tar.gz
SHA256 hash:
3328a41c45201e0e8cb61dd8941bac498dbb70d2d555e417cef8f60f5a9f64a6
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzpEAAoJEMK/C8Qzz8izUYYH/A9jC094IFims8KGm+T9Y+7t
Pndp8bdczLL+2Tcaze4+RBeo/KiYjmSFaDiOy1sH/rc7w2r/J7Fqt6w3SPAGHGGB
kJfmweAJDHvmsqRAZLtW0lby8nMx4EZvvMz6YJektzEioM3MFPUYYfkQrF3HeRAZ
j7tXYH3FQ5hkcOI0vPiDjq2Ex/ZRdT5w4Vxt5INIs+JhXgE8QuZEKmLm+Kp0Rqfx
S7XSYno1xeko92Yaigf+qYQWzw26y/cxK4EhmRWrF7Zjs3o58thLl05BfjjaLuLD
3oFKTNo+PEZeyNAOR5TjoxMo3RHnj5NRUE0qJQyyPi+PwIAJvj0ZaqlHO7kPa/E=
=pAe3
-END PGP SIGNATURE-

php-5.6.21RC1.tar.xz
SHA256 hash:
664da21306560d5b385502e814f5f06f4cc3a1eb842ad01ce6f897e2a1a7f619
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXFzpJAAoJEMK/C8Qzz8izbLcH/3uHLuKFnt1HoYU4x2dHe2FI
+SbhZpEsWpxOAKvMgUQ2g/yX9qStMr6f2WbAiM1gwpklpf1zi+8atIHF3/dTDAIv
ORdfKf83f7U2hiRpUd9Madd9XWEZ6q45PmEtsKV96IahfqZHney+WeV/cLcELg/E
/iekdCoB5slagAwt83h/nvJ7f+qaJ34KTWcjNEVj4HSQzA8SFV0RgAGmnQHWY8oU
wmRLTl6vOUcCfxAjFh+p5jnG6Y+m3qgsfItEgwfFJ4goMQT64M6w2j+n8F9DuGN7
Kao+EFJZSg5KqKViK0aJ8/Vz/tuoyj3lk3CE3m+wafSjWkuTceDg5ogLb8TpUNs=
=giOn
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli

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

[Mathieu Rochette]

On 20/04/2016 00:22, Sara Golemon wrote:

On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette  wrote:

about the upper bounds, have you consider another way of describing the
constraints, eg:

class Box where T is Boxable

this would allow multiple constraints, eg:

class Collection where T is Traversable, T is Countable


IMO, this sort of problem should be solved by combining this feature
with union types, so you could have something like:

class Collection {...

And merely inherit the logic rules from that feature rather than
inventing yet another one.
obviously if the union type rfc passes we don't need another way of 
expressing this.
that was only in the case it does not, I think having a way to have at 
least types intersection

is useful here (and I didn't event think about )



can generic types be nested ?

class Stuff>


I can't imagine why not...
just to be clear, it's not just nested generic. the A type have to be 
same in both "subtypes"


For my part, I love the concept overall.  Generics are an important
part of moving PHP towards comprehensive type-safety.  But then, you
know how I feel about Hack. :)

-Sara




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

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

[Jesse Schalken]

Without type annotations:

function foo($b) {

if (!is_string($b)) {

// Ugh, why can't the language enforce this?

throw new Exception("needed a string");

}

}


With type annotations:

function foo(string $b) {

// I know $b is a string. I don't need to check. :)

}


Without unions:

function foo($b) {
if (is_string($b)) {
// ...
} else if ($b instanceof Bar) {
// ...

} else {

   // Ugh, why can't the language enforce this?

throw new Exception("needed a string|Bar");

}

}


With unions:

function foo(Bar|string $b) {

if (is_string($b)) {
// ...
} else {
// I know $b is a Bar here. I don't need to check. :)
}
}


In both cases, the type annotation has removed the 1 check and the need to
throw an exception. It's the exact same benefit.


On Sat, Apr 16, 2016 at 1:10 AM, Andrea Faulds  wrote:

> Hi Stas,
>
> Stanislav Malyshev wrote:
>
>> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>> since it is super self-explanatory. However, I find myself checking the
>>>
>>
>> It may be self-explanatory for you. It's much less self-explanatory for
>> somebody just starting to learn. It is also very dangerous - if it's
>> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
>> or not string, can you call strlen on it? Etc., etc. It adds a lot of
>> cognitive load and complicates the whole picture. You may have a
>> specific use case where it is useful (which we have yet to see btw) but
>> please remember it's a language with literally millions of use cases and
>> users.
>>
>
> This is something that particularly concerns me about union types, in that
> they reduce type safety. If you have a union type of Foo|Bar for some
> variable, then the set of methods you can call on that variable is actually
> the intersection, not the union, of the set of methods you can call on Foo
> and Bar. Which, unless those two classes share some interface, is probably
> an empty set. So there's nothing you can actually do safely with it without
> doing checks within the body of the function, and if you're doing that,
> then why do we have a type declaration? It's only barely more useful than
> omitting a type declaration at all; type declarations are supposed to
> prevent you needing to check. On the other hand, if the two classes share
> some methods, then either there's an interface you can already use here, or
> you can create one. Either way, you don't need a union type.
>
> There are some cases where you can't create an interface, but if that's
> the case, I think it is more worthwhile to look at how we can fix those
> cases, rather than add what amounts to a hacky workaround.
>
> Thanks!
> --
> Andrea Faulds
> https://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

[Joe Watkins]

Oh, I fixed it ... I think ... carry on ...

Cheers
Joe

On Wed, Apr 20, 2016 at 7:01 AM, Joe Watkins  wrote:

> Can we just halt this conversation for a few days.
>
> That implementation is totally and utterly wrong, it's so obvious this
> morning ... I'm almost embarrassed.
>
> I must say that of all the suggestions made so far for syntax, I still
> prefer use().
>
> While the idea to allow symbols and expressions is very cool, it will
> create so much confusion that an anonymous class can do things like set
> objects as member properties but other classes can't.
>
> The syntax also looks absolutely terrible when it comes to refs:
>
> class {
> public $thing = &$this->thing;
> }
>
> This is almost literally *backwards*.
>
> All of the solutions suggested so far also create rather a lot of
> repetition for anything that isn't example code.
>
> Anyway, the implementation is broken, let's come back to this discussion
> later on, please.
>
> Cheers
> Joe
>
> On Wed, Apr 20, 2016 at 4:54 AM, Jesse Schalken 
> wrote:
>
>> I'm not sure it matters, but there is some precedent for this in
>> JavaScript/ES6:
>>
>> function foo(bar) {
>> return new class {
>> myBar = bar;
>>
>> getBar() {
>> return this.myBar;
>> }
>> }();
>> }
>>
>> console.log(foo('hello').getBar()); // "hello"
>>
>>
>> (You can actually reference outer symbols anywhere in the definition of a
>> JS class, so I could have used "bar" directly in "getBar" without going
>> through a property.)
>>
>>
>> On Wed, Apr 20, 2016 at 12:18 AM, Nikita Popov 
>> wrote:
>>
>>> On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins 
>>> wrote:
>>>
>>> > Morning Internals,
>>> >
>>> > Please review the following RFC:
>>> >
>>> > https://wiki.php.net/rfc/lexical-anon
>>> >
>>> > A look at the patch from those of you that do that would be good :)
>>> >
>>>
>>> Hey Joe,
>>>
>>> The syntax and semantics proposed in this RFC don't sit quite well with
>>> me.
>>> Especially the fact that a use($foo) on the class is then used as
>>> $this->foo in methods is non-intuitive to me, as it differs from how the
>>> same syntax behaves on closures. I'd like to suggest an alternative
>>> syntax:
>>>
>>> $foo = 42;
>>> return new class {
>>> private $bar = $foo;
>>> public function getBar() { return $this->bar; }
>>> }
>>>
>>> That is, allow properties inside the anonymous class to be initialized
>>> based on values from the surrounding scope. This is more explicit
>>> (clearly
>>> shows that a property is being created), it allows explicit control over
>>> the visibility and, depending on implementation, might be more flexible
>>> with regards to the values it accepts. It probably doesn't make sense to
>>> restrict this to specific expressions, so all of
>>>
>>> return new class {
>>> private $a = $var;
>>> private $b = $obj->prop;
>>> private $d = $obj->prop ?? 'default';
>>> // ...
>>> }
>>>
>>> could be fine.
>>>
>>> Thanks,
>>> Nikita
>>>
>>
>>
>

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

[Joe Watkins]

Can we just halt this conversation for a few days.

That implementation is totally and utterly wrong, it's so obvious this
morning ... I'm almost embarrassed.

I must say that of all the suggestions made so far for syntax, I still
prefer use().

While the idea to allow symbols and expressions is very cool, it will
create so much confusion that an anonymous class can do things like set
objects as member properties but other classes can't.

The syntax also looks absolutely terrible when it comes to refs:

class {
public $thing = &$this->thing;
}

This is almost literally *backwards*.

All of the solutions suggested so far also create rather a lot of
repetition for anything that isn't example code.

Anyway, the implementation is broken, let's come back to this discussion
later on, please.

Cheers
Joe

On Wed, Apr 20, 2016 at 4:54 AM, Jesse Schalken 
wrote:

> I'm not sure it matters, but there is some precedent for this in
> JavaScript/ES6:
>
> function foo(bar) {
> return new class {
> myBar = bar;
>
> getBar() {
> return this.myBar;
> }
> }();
> }
>
> console.log(foo('hello').getBar()); // "hello"
>
>
> (You can actually reference outer symbols anywhere in the definition of a
> JS class, so I could have used "bar" directly in "getBar" without going
> through a property.)
>
>
> On Wed, Apr 20, 2016 at 12:18 AM, Nikita Popov 
> wrote:
>
>> On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins 
>> wrote:
>>
>> > Morning Internals,
>> >
>> > Please review the following RFC:
>> >
>> > https://wiki.php.net/rfc/lexical-anon
>> >
>> > A look at the patch from those of you that do that would be good :)
>> >
>>
>> Hey Joe,
>>
>> The syntax and semantics proposed in this RFC don't sit quite well with
>> me.
>> Especially the fact that a use($foo) on the class is then used as
>> $this->foo in methods is non-intuitive to me, as it differs from how the
>> same syntax behaves on closures. I'd like to suggest an alternative
>> syntax:
>>
>> $foo = 42;
>> return new class {
>> private $bar = $foo;
>> public function getBar() { return $this->bar; }
>> }
>>
>> That is, allow properties inside the anonymous class to be initialized
>> based on values from the surrounding scope. This is more explicit (clearly
>> shows that a property is being created), it allows explicit control over
>> the visibility and, depending on implementation, might be more flexible
>> with regards to the values it accepts. It probably doesn't make sense to
>> restrict this to specific expressions, so all of
>>
>> return new class {
>> private $a = $var;
>> private $b = $obj->prop;
>> private $d = $obj->prop ?? 'default';
>> // ...
>> }
>>
>> could be fine.
>>
>> Thanks,
>> Nikita
>>
>
>