Re: [PHP-DEV] Final properties

On 14. apr. 2016, at 11.47, Lester Caine wrote: > >> On 14/04/16 08:52, André Rømcke wrote: >> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 > > This actually summarises many of the problems all of these 'extras' are > creating for very little gain. > > 'Seconds' is

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

On 4/15/16 1:58 PM, Dmitry Stogov wrote: A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types You proposed the ?Something grammar. With ?: and ?? appearing in recent PHP and proposals for ??= if not ?:= and now this, I feel we're heading to regex hell :p

Re: [PHP-DEV] Trying to fix "use" language inconsistencies

I thought there was one already? https://wiki.php.net/rfc/group_use_declarations On Sat, Apr 16, 2016 at 9:01 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Hi internals, > > > It all started with a PR over doctrine/annotations ( >

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

If we can pre-define the types via something like this: data Tree a = Branch (Tree a) (Tree a) | Leaf a And only allow one type for each function parameter in the prototype, then, I think the performance impact of type checking in the runtime can be reduced. In other words, you predefine the

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

I pretty much like the Haskell type system, it let you define types via the syntax below: data Tree a = Branch (Tree a) (Tree a) | Leaf a But the type inference in Haskell can be resolved in the compile-time. We can only verify the variable type for each function call in PHP.

[PHP-DEV] Trying to fix "use" language inconsistencies

Hi internals, It all started with a PR over doctrine/annotations ( https://github.com/doctrine/annotations/pull/69), where a contributor decided to propose supporting group use support. The issue starts with this, which it is perfectly supported: use Foo\Bar, Foo\Woo; While multiple group

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

On Sat, Apr 16, 2016 at 1:28 AM, Christoph Becker wrote: > On 15.04.2016 at 17:42, Larry Garfield wrote: > > Maybe we should consider to accept an array as Traversable? Actually, I > wonder why that's not already the case. > +1, I think so too. -- Best Regards, Yo-An Lin

Re: [PHP-DEV] Typed properties patch

On 15/04/16 22:01, Yasuo Ohgaki wrote: >> public Node | null $left; > Value must be able to be NULL. > SQL has "NOT NULL" constraint. We may have "MAY NULL" and > this syntax seems reasonable choice. While the value of a field may be constrained as NOT NULL, it may also be defined as DEFAULT xxx

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

Hi! > All of PHP users _should_ avoid probability based GC > whenever it is possible. Why we shouldn't have API that kills > custom of probability based usage? No, they shouldn't. Just claiming that your favorite use case should fit everybody does not make it so. -- Stas Malyshev

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

Hi Stas, On Wed, Apr 13, 2016 at 2:25 AM, Stanislav Malyshev wrote: >> Lack of proper API for required task is our problem. Misuse is not ours. >> IMHO. > > No, it is our problem. We can't just create whatever and throw it over > the fence. The properly designed API has to

Re: [PHP-DEV] Typed properties patch

Hi all, On Thu, Apr 7, 2016 at 9:44 PM, Bob Weinand wrote: >> 1) While parameters allow null to be accepted as the default value, null is >> never a valid value for a typed property. >> >> I think we must have a way to make properties explicitly nullable. Otherwise >> we

Re: [PHP-DEV] Re: Typed properties patch

Hi! > In most cases we avoid IS_UNDEF checks, verifying the most probable expected > types first. But that's for something like ADD, not for property fetches, so I'm not sure I understand how properties fit there yet. Does the optimization also track the variable after fetching? In any case,

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

On 15/04/16 18:58, Dmitry Stogov wrote: > I'm sure, union types bring too many conceptual and implementation questions, > and I even don't speak abut intersections. The one problem I see with all of this is that it is reliant on every single variable being passed in when in early PHP5 days the

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

On 4/15/16 12:28 PM, Christoph Becker wrote: On 15.04.2016 at 17:42, Larry Garfield wrote: I think there's 2 general use cases for union types that would be "good things", which are different for & and |, and have very little... intersection. (*yaaa!*) The OR case is for cases where the

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

On 4/15/16 12:16 PM, Lin Yo-An wrote: Andrea Faulds 於 2016年4月15日 星期五寫道： 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

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

A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same). I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut

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

On 15.04.2016 at 17:42, Larry Garfield wrote: > I think there's 2 general use cases for union types that would be "good > things", which are different for & and |, and have very little... > intersection. (*yaaa!*) > > The OR case is for cases where the language doesn't support a unified >

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

On 4/14/16 3:50 AM, Dmitry Stogov wrote: The up to date implementation for return-type-hints may be found at https://github.com/php/php-src/pull/1851/files Splendid! Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1]. Tom [1] https://wiki.php.net/rfc/nullable_returns --

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/15/16 12:22 AM, Levi Morrison wrote: My point is that `foo(bar(), $val)` won't die because bar may return null. Bar is expected to return null sometimes. For example, let's consider an administrator page where they look up user information based on an identifier. The routine we'll use

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

Andrea Faulds 於 2016年4月15日 星期五寫道： > > > 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,

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/14/16 8:48 PM, Larry Garfield wrote: I am highly, highly sceptical about nullable parameters or returns, and frankly would rather they were not included in the language. By nature they undermine type safety. At best, they indicate to all callers "*every* time you call this function, you

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

On 14.04.2016 at 21:32, Jordi Boggiano wrote: > I don't really think it's much more complex to grasp `Foo|Bar $foo` than > only `Foo $foo`. I mean once you grasp the concept of type hints you > probably have by then a good understanding of || and hopefully can > derive understanding from there. >

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

On 4/14/16 3:25 PM, Fleshgrinder wrote: On 4/14/2016 8:59 PM, Stanislav Malyshev wrote: >Hi! > >>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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

> convinced by the rebuttles to change my mind. s/rebuttles/rebuttals/ I thought about just letting it go like many typos/spelling mistakes but it seemed too funny to not correct -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

> I'm not suggesting that we purge NULL from the language. That's > impractical/impossible. I'm suggesting we shouldn't soften the type system > added in 7.0, which discourages its use in most cases, as it should be. It is a common misconception I've heard several times now that union types is

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

On 4/13/16 5:06 PM, Stanislav Malyshev wrote: Types are designed in a way enhancing the languages experience while avoiding nearly every impact for people who want to ignore them. This is not true. If it's in language, you have to understand it to be able to use the language. Nobody writes

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/15/16 4:55 AM, Lester Caine wrote: On 15/04/16 05:22, Levi Morrison wrote: Unless you like having is_null() scattered around your code in a hundred places... I don't. :-) You have lots of code instead in exception handling away fro the normal program flow? [1]

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

On 4/15/16 10: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

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

> This is something that particularly concerns me about union types, in that > they reduce type safety. This is incorrect. Anyone using a union type now simply uses PHP's dynamic type system. Going from no enforced type to restricting it to N types does not in any circumstance reduce type safety.

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

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

Re: [PHP-DEV] Interpolation using ${} syntax with spaces inside the braces

Simon Welsh wrote on 15/04/2016 00:52: When not inside a string, the inside of the ${...} is always treated as an expression, by both PHP and HHVM (https://3v4l.org/i2kOP), so that looks like the “correct” handling for inside a string. The in-quotes behaviour makes sense when you consider the

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

Results for project PHP master, build date 2016-04-15 06:35:50+03:00 commit: 60b1441 previous commit:a186ac0 revision date: 2016-04-07 10:26:32+09: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] [RFC] Nullable Return Type Declaration

On 15/04/16 05:22, Levi Morrison wrote: >> Unless you like having is_null() scattered around your code in a hundred >> > places... I don't. :-) You have lots of code instead in exception handling away fro the normal program flow? >> > [1]

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

Tony, that sounds really like "real programmers use `dd -if -of`". Please stop with that argument, as it really doesn't reflect reality. I keep enhancing my software with new (stricter) type checking, when available. For example, I'm eager to replace current docblocks declaring `void` methods with

[PHP-DEV] Re: optimization for function call without paremters

I think this optimization could be done by two approach: 1. Add another FCALL op, which init a function call and call that function directly for functions without parameters. 2. Let the original INIT_FCALL support "call function when the number of parameter == 0" On Fri, Apr 15, 2016 at 5:27

[PHP-DEV] optimization for function call without paremters

Hi Dmitry, I found that INIT_FCALL doesn't use opline->result.var and DO_ICALL doesn't use op1 or op2. The original purpose of separating these two op was for sending parameters. However, if a function doesn't need parameters and it's an internal function, I think the operation could be merged

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

"Levi Morrison" wrote in message news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com... There are too many people out there who are trying to make the language more complicated than it need be just to prove how clever they are. I can assure you I am not proposing these