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

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

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

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

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

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

[PHP-DEV] Quick sanity check ...

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

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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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.

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

[PHP-DEV] Safe timeout handling

Hi, It's a well known PHP problem, that exceeding of execution time-out (max_execution_time) may lead to unexpected crashes. They occur because PHP may be interrupted in inconsistent state, and attempt to release allocated by request resources leads to failure. Almost any big site sees these

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] Safe timeout handling

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] Safe timeout handling

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

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

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

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

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

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

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

Re: [PHP-DEV] Safe timeout handling

> 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

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

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

Re: [PHP-DEV] Safe timeout handling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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