"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 RF
On Thu, Apr 14, 2016 at 6:48 PM, Larry Garfield wrote:
> On 04/14/2016 07:33 PM, Tom Worster wrote:
>>
>> On 4/14/16, 5:46 PM, "Levi Morrison" > le...@php.net> wrote:
>>
>>> Having a separate method instead of `foo(null, "value")` makes it
>>> difficult to use for the result of a function.
>>
>> I
On 04/14/2016 07:33 PM, Tom Worster wrote:
On 4/14/16, 5:46 PM, "Levi Morrison" wrote:
Having a separate method instead of `foo(null, "value")` makes it
difficult to use for the result of a function.
I suspect that might be a good thing:) I don't know for sure but the
possibility exists.
A
On 4/14/16, 5:46 PM, "Levi Morrison" wrote:
>Having a separate method instead of `foo(null, "value")` makes it
>difficult to use for the result of a function.
I suspect that might be a good thing:) I don't know for sure but the
possibility exists.
>Assume `bar()` returns
>`Bar | Null`; this wo
> On 15/04/2016, at 9:40 AM, Sara Golemon wrote:
>
> On Thu, Apr 14, 2016 at 3:37 AM, Davey Shafik wrote:
>> Whitespace inside of { } should not matter, the contents should be evaluated
>> as an expression and it's results used to determine the variable name, so
>> ${great} should also be $my as
On Thu, Apr 14, 2016 at 3:37 AM, Davey Shafik wrote:
> Whitespace inside of { } should not matter, the contents should be evaluated
> as an expression and it's results used to determine the variable name, so
> ${great} should also be $my as in the other cases.
>
Right. Which is why I'm conflicted
>>Why not allow nullable types on parameters to avoid that wonkiness
>>caused by default values of null?
>>
>>function foo(Bar | Null $b, $not_optional_param);
>>
>>This is much better.
>
> Yes but still a code smell to me. I'd need to know more about the
> programmer's intent for `foo(null, "v
On 4/14/16, 1:33 PM, "Fleshgrinder" wrote:
>On 4/14/2016 6:35 PM, Levi Morrison wrote:
>>I can appreciate that you want only the restricted union with null.
>> However, I do not see the point of disallowing it for parameter types
>>
>My guess is that this RFC only wants to get it for return becau
On 4/14/16, 12:35 PM, "Levi Morrison" wrote:
>I can appreciate that you want only the restricted union with null.
>However, I do not see the point of disallowing it for parameter types
>while allowing it for return types:
>
>function setLeft(Node $n = null) {
>$this->left = $n;
>
> -Original Message-
> From: Tony Marston [mailto:tonymars...@hotmail.com]
> Sent: Thursday, April 14, 2016 12:01 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>
> "Zeev Suraski" wrote in message
> news:5b147e88-cc0a-4cbc-a49d-c7fe3bf55...@zen
Hi,
PHP 7.0.6 RC1 was just released and can be downloaded from:
https://downloads.php.net/~ab/
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
Hi!
>> Reduce assertions*, enhance self-documentation, making code more robust,
>> perform checks in the VM and not in userland, ...
You don't reduce assertions, you just make them more cryptic and change
error message slightly.
> Oh oh oh, I forgot the very important unions *int|string* and
> *
Stas, you have to look into "master" branch code.
In most cases we avoid IS_UNDEF checks, verifying the most probable expected
types first.
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *resul
Heya,
On 14/04/2016 19:59, 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
On 4/14/2016 9: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'
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 less self-explanatory for
> somebody just
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 less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
eith
On 4/14/2016 2:47 PM, Lin Yo-An wrote:
> But weak type conversion and union type are not, it introduces more complex
> rules of how variables should be converted into another values, and there
> will be more implementation defined behavior. People will have to always
> have a cheatsheet or somethin
On 4/14/2016 5:42 AM, 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 th
On 4/14/2016 6:35 PM, Levi Morrison wrote:
> On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster wrote:
>> I would like to introduce for discussion an RFC proposing and arguing for
>> Nullable Return Type Declaration in 7.1 and deferring for now more general
>> relaxations of 7.0 type as proposed in Levi
Hi!
> I didn't understand.
> Of course we keep a class definition, where the type of property "$a" -
> IS_LONG, but the actual value of "$a" may become IS_UNDEF.
What I'm saying is maybe it's fine.
> In PHP-7 we check for IS_LONG without type hint.
> With type hint and ability to unset(), we wil
On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster wrote:
> I would like to introduce for discussion an RFC proposing and arguing for
> Nullable Return Type Declaration in 7.1 and deferring for now more general
> relaxations of 7.0 type as proposed in Levi's two RFCs.
>
> https://wiki.php.net/rfc/null
On 4/13/16 11:46 PM, Levi Morrison wrote:
As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types.
I look forward to a helpful and meaning
I would like to introduce for discussion an RFC proposing and arguing for
Nullable Return Type Declaration in 7.1 and deferring for now more general
relaxations of 7.0 type as proposed in Levi's two RFCs.
https://wiki.php.net/rfc/nullable_returns
If anyone would like to collaborate on the RFC,
> Also, just to clarify, if you combine this with the nullable types syntax
> (assuming prefix), then the nullable applies to the entire union type:
>
> ?int|float === int | float | null
>
> I do find the shorter syntax confusing TBH.
>
> Which actually leads me to a different thought: defining cus
> 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 RFCs to show how clever I am.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu, Apr 14, 2016 at 3:12 AM, Derick Rethans wrote:
> On Wed, 13 Apr 2016, Levi Morrison wrote:
>
>> As alluded to in an earlier email today[1] I am now moving the Union
>> Types RFC[2] to the discussion phase. The short summary of the RFC is
>> that it permits a type declaration to be one of s
On Thu, Apr 14, 2016 at 5:44 PM, Alain Williams wrote:
> On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:
>
> > I agree with Zeev 100%. 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.
On 4/11/16 6:11 PM, Sara Golemon wrote:
On Mon, Apr 11, 2016 at 9:36 AM, Stanislav Malyshev wrote:
The point is even imperfect detection may be useful in certain
circumstances, and detector being part of ICU hints that people find it
useful enough to spend time implementing and supporting it. W
Derick Rethans 於 2016年4月14日 星期四寫道:
> On Thu, 14 Apr 2016, Lin Yo-An wrote:
>
> > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans > wrote:
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass vari
Results for project PHP master, build date 2016-04-14 06:35:07+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
2015-04-28 11:29 GMT+03:00 Johannes Ott :
> Am 13.04.2015 um 15:37 schrieb Johannes Ott:
>> Hi,
>>
>> finally I managed to do my first RFC draft.
>>
>> https://wiki.php.net/rfc/static_class_constructor
>>
>> I hope I have done everything correct so far and I'm looking forward to
>> your feedback on
Whitespace inside of { } should not matter, the contents should be
evaluated as an expression and it's results used to determine the variable
name, so ${great} should also be $my as in the other cases.
Is this related to the use of quotes around string array keys inside
strings?
e.g. "$foo[great]
As mentioned in my nullable types comment, I think that we should NOT add a
Null type unless the nullable types RFC fails to pass. We should not
introduce both options, and I favor the nullable types over this for that
purpose.
With regards to Dericks comment on type conversion, I think either sim
On 14/04/16 10:59, Davey Shafik wrote:
On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans wrote:
On Wed, 13 Apr 2016, 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 d
On 14/04/16 10:00, Tony Marston wrote:
> I have been programming for over 30 years, so in no way can I be classed
> as a newbie. PHP is my favourite language because of its simplicity. I
> started with PHP 4, and although I have upgraded to PHP 5 I refuse to
> use any of the "clever" additions whic
On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans wrote:
> On Wed, 13 Apr 2016, 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 alternative
On 13/04/16 21:24, Stanislav Malyshev wrote:
>> May I suggest you the following article (more of a starting point into
>> > Ceylon actually) regarding this topic:
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs
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 Property' so is untyped and if accessed as a
value from some OS's will b
On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:
> I agree with Zeev 100%. 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. The aim of any language should be to
> enable programmers to do co
On Thu, 14 Apr 2016, Lin Yo-An wrote:
> On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans wrote:
>
> > I think what I am missing in the RFC is behaviour with scalar (weak)
> > typehints, and which type the variable in a class would be converted to.
> > Take for example:
> >
> > function foo(int|bo
On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans wrote:
> I think what I am missing in the RFC is behaviour with scalar (weak)
> typehints, and which type the variable in a class would be converted to.
> Take for example:
>
> function foo(int|bool $var) { echo get_type( $var ), "\n"; }
>
> foo(5);
On Wed, 13 Apr 2016, Levi Morrison wrote:
> As alluded to in an earlier email today[1] I am now moving the Union
> Types RFC[2] to the discussion phase. The short summary of the RFC is
> that it permits a type declaration to be one of several enumerated
> types. For example, this is a potential si
On Mon, 11 Apr 2016, Sara Golemon wrote:
> With a light push from Stas, I've decided to go ahead and put up
> IntlCharsetDetector for discussion.
> https://wiki.php.net/rfc/intl.charset-detector
>
> I'm still not personally convinced this API is trustworthy enough, but
> it's worth a formal discu
"Zeev Suraski" wrote in message
news:5b147e88-cc0a-4cbc-a49d-c7fe3bf55...@zend.com...
On 14 ? 2016, at 7:14, Larry Garfield wrote:
On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
Hi!
May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this
On Wed, 13 Apr 2016, 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 t
I think this will add more complexity to the runtime system. The type
hinting will be something we use to generate good JIT code, not just for
checking types.
Dmitry Stogov 於 2016年4月14日 星期四寫道:
> The RFC doesn't say anything about support for multiple class names.
>
> function foo(A|B|C $x)
>
>
On 04/13/2016 10:31 PM, Stanislav Malyshev wrote:
Hi!
Because if you unset() a property it's type is not guaranteed anymore.
Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?
I didn't understand.
Of course
The RFC doesn't say anything about support for multiple class names.
function foo(A|B|C $x)
Support for multiple classes would lead to complex implementation.
Thanks. Dmitry.
From: Levi Morrison
Sent: Thursday, April 14, 2016 06:46
To: internals
Subjec
> On 14 Apr 2016, at 00:36 , Stanislav Malyshev wrote:
>
> With getters/setters, the answer is clear - yes, you can extend it with
> setters, but if your invariant relies on immutability, you'd be
> violating LSP. With properties, not clear.
So in summary preference would be that something l
On 04/14/2016 06:42 AM, 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.
+1
The up to date implementation for return-type-hin
51 matches
Mail list logo