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 a 'Traditional Proper
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
T
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 (
> https://github.com/doctrine/annotations/pull
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 un
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.
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 uses
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
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 w
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
smalys...@gmai
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 make correct use very
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 won't be able to define
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, to
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 pr
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 l
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 is actually
t
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 in
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
> ca
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
--
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 will
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, not the union
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 M
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.
>
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 le
> 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
> 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 we
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 cod
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] https://en.wikipedia.org/
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
> 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.
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
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
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
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] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_ret
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
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 PM,
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 i
36 matches
Mail list logo
