date:20160414

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 suspect that might be a good thing:) I don't know for sure but the
>> possibility exists.
>>
>>
>>> Assume `bar()` returns
>>> `Bar | Null`; this would no longer work if they were separated:
>>>
>>> foo(bar(), "value")
>>>
>>> Functions are often composed so if something is the output of one
>>> function it will likely be the input to another. Thus if returning
>>> optionally null values is important to you so should optionally null
>>> parameters.
>>
>> This was a chin-scratcher for me. On one hand, I see what you mean. On the
>> other I couldn't think of an example from my experience (which I admit is
>> very narrow -- I live a sheltered life) of such a bar() that I would feed
>> straight foo().
>>
>> The semantic convention for Something or null return, as I see it, is when
>> bar() returns null, it is saying "I got nothing". What kind of foo() does
>> the same thing to nothing at all as it does to a Something object? This is
>> where I got stuck.
>>
>> Say I was doing the composition instead via chaining.
>> Something::bar()->foo("value") is nonsense if bar() could return null.
>> This suggests to me that the other composition might not be wise.
>>
>> *Either* bar() should not be returning Something or null (maybe it should
>> instead return some other type that can represent all the possible
>> returns) *or* we shouldn't try to compose like this and should test for
>> the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
>> "value") to it. Or maybe this API needs an even more fundamental redesign.
>>
>> So, from my perspective, this might be an example of the limitation
>> nudging us to think harder about the design.
>>
>> Tom
>
>
> I have to agree with Tom.  if foo(bar(), $val) could die because bar() may
> return NULL, that's not an indication that foo() needs to accept NULL.  It's
> a sign that bar() should not be returning it in the first place. :-)
>
> 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 MUST put is_null() around it or your program may
> fail randomly."  While that's better to know explicitly than not (which is
> the case for any untyped return, aka any PHP code pre-7.0), it would be
> better still to, well, not have to worry about that billion dollar
> mistake[1] cropping up in my code.
>
> In a sense, if we really must allow for value-or-null (which I consider a
> code smell in the 98% case) I'd prefer if it was ONLY available via union
> types: That is, Something|null.  That's longer and clumsier to type, and
> harder to read.  Which it should be. (Static casts in C++ have a fugly
> syntax, which has been defended by the language designers on the grounds
> that static casts are fugly, so the syntax for them should be as well to
> remind you to stop doing it. There is a fair amount of validity to that
> argument on affordance grounds, at least within C++.)  Using an easy short
> hand notation for something that is inherently a code smell when you're
> already typing your code only serves to encourage something we should be
> training people out of in the first place.
>
> Unless you like having is_null() scattered around your code in a hundred
> places...  I don't. :-)
>
> [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
>
> --Larry Garfield

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
have this signature:

function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

$user_data = get_user($id);
// ...
$user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).

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

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

2016-04-14 Thread Larry Garfield


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.



Assume `bar()` returns
`Bar | Null`; this would no longer work if they were separated:

foo(bar(), "value")

Functions are often composed so if something is the output of one
function it will likely be the input to another. Thus if returning
optionally null values is important to you so should optionally null
parameters.

This was a chin-scratcher for me. On one hand, I see what you mean. On the
other I couldn't think of an example from my experience (which I admit is
very narrow -- I live a sheltered life) of such a bar() that I would feed
straight foo().

The semantic convention for Something or null return, as I see it, is when
bar() returns null, it is saying "I got nothing". What kind of foo() does
the same thing to nothing at all as it does to a Something object? This is
where I got stuck.

Say I was doing the composition instead via chaining.
Something::bar()->foo("value") is nonsense if bar() could return null.
This suggests to me that the other composition might not be wise.

*Either* bar() should not be returning Something or null (maybe it should
instead return some other type that can represent all the possible
returns) *or* we shouldn't try to compose like this and should test for
the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
"value") to it. Or maybe this API needs an even more fundamental redesign.

So, from my perspective, this might be an example of the limitation
nudging us to think harder about the design.

Tom


I have to agree with Tom.  if foo(bar(), $val) could die because bar() 
may return NULL, that's not an indication that foo() needs to accept 
NULL.  It's a sign that bar() should not be returning it in the first 
place. :-)


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 MUST put is_null() around it 
or your program may fail randomly."  While that's better to know 
explicitly than not (which is the case for any untyped return, aka any 
PHP code pre-7.0), it would be better still to, well, not have to worry 
about that billion dollar mistake[1] cropping up in my code.


In a sense, if we really must allow for value-or-null (which I consider 
a code smell in the 98% case) I'd prefer if it was ONLY available via 
union types: That is, Something|null.  That's longer and clumsier to 
type, and harder to read.  Which it should be. (Static casts in C++ have 
a fugly syntax, which has been defended by the language designers on the 
grounds that static casts are fugly, so the syntax for them should be as 
well to remind you to stop doing it. There is a fair amount of validity 
to that argument on affordance grounds, at least within C++.)  Using an 
easy short hand notation for something that is inherently a code smell 
when you're already typing your code only serves to encourage something 
we should be training people out of in the first place.


Unless you like having is_null() scattered around your code in a hundred 
places...  I don't. :-)


[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

--Larry Garfield

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

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

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 would no longer work if they were separated:
>
>foo(bar(), "value")
>
>Functions are often composed so if something is the output of one
>function it will likely be the input to another. Thus if returning
>optionally null values is important to you so should optionally null
>parameters.

This was a chin-scratcher for me. On one hand, I see what you mean. On the
other I couldn't think of an example from my experience (which I admit is
very narrow -- I live a sheltered life) of such a bar() that I would feed
straight foo().

The semantic convention for Something or null return, as I see it, is when
bar() returns null, it is saying "I got nothing". What kind of foo() does
the same thing to nothing at all as it does to a Something object? This is
where I got stuck.

Say I was doing the composition instead via chaining.
Something::bar()->foo("value") is nonsense if bar() could return null.
This suggests to me that the other composition might not be wise.

*Either* bar() should not be returning Something or null (maybe it should
instead return some other type that can represent all the possible
returns) *or* we shouldn't try to compose like this and should test for
the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
"value") to it. Or maybe this API needs an even more fundamental redesign.

So, from my perspective, this might be an example of the limitation
nudging us to think harder about the design.

Tom

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

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

2016-04-14 Thread Simon Welsh

> 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 in the other cases.
>> 
> Right.  Which is why I'm conflicted on bug/not-bug/different-bug.
> 
> IMO, the label inside ${...} should either always be a variable name
> (like HHVM handles it), or always be an expression.  What we have is
> "It's always an expression except in the one specific case of it being
> a valid variable name, in which case that takes precedence.  Since the
> versions containing spaces aren't valid variable names, they fall back
> on the more general expression handling.
> 
> So I'd be inclined to say "That exception to the rule is the problem",
> except that this is variable interpolation behavior that goes ALL THE
> WAY BACK, and I wouldn't break BC for the world.
> 
> So the question becomes: What's the right move going forward.  My
> inclination would be to either:
> A: Ignore surrounding whitespace within the ${...} expression.
> Essentially, adopt HHVM's output for these examples.
> B: Throw an error on surrounding whitespace.  This will make
> discovering timebombs like these in existing code easier to catch.
> 
> In either case, if the programmer actually did want the
> constant->variable double-interpolation, that could be easily achieved
> via "${(foo)}" which disambiguated foo as a variable name from foo as
> an expression.
> 
> -Sara
> 
>> Is this related to the use of quotes around string array keys inside
>> strings?
>> 
>> e.g. "$foo[great]" does not evaluate to $foo['my'] but to $foo['great'].
>> 
> I don't think so... I have a feeling that's yet another weird oddity
> to PHP parsing that's waiting to bite us in new and surprising ways.
> 
> -Sara

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.

There is also differing behaviour in PHP when using array access, depending on 
if
the label starts with a space or not (https://3v4l.org/YPXkr). This behaviour is
inconsistent with not using array access. HHVM follows the <=PHP5.5 behaviour of
not allowing array access on a constant.

However, there is the massive BC break if the handling inside a string changes
-- 
Simon Welsh




smime.p7s
Description: S/MIME cryptographic signature

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

2016-04-14 Thread Sara Golemon

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 on bug/not-bug/different-bug.

IMO, the label inside ${...} should either always be a variable name
(like HHVM handles it), or always be an expression.  What we have is
"It's always an expression except in the one specific case of it being
a valid variable name, in which case that takes precedence.  Since the
versions containing spaces aren't valid variable names, they fall back
on the more general expression handling.

So I'd be inclined to say "That exception to the rule is the problem",
except that this is variable interpolation behavior that goes ALL THE
WAY BACK, and I wouldn't break BC for the world.

So the question becomes: What's the right move going forward.  My
inclination would be to either:
A: Ignore surrounding whitespace within the ${...} expression.
Essentially, adopt HHVM's output for these examples.
B: Throw an error on surrounding whitespace.  This will make
discovering timebombs like these in existing code easier to catch.

In either case, if the programmer actually did want the
constant->variable double-interpolation, that could be easily achieved
via "${(foo)}" which disambiguated foo as a variable name from foo as
an expression.

-Sara

> Is this related to the use of quotes around string array keys inside
> strings?
>
> e.g. "$foo[great]" does not evaluate to $foo['my'] but to $foo['great'].
>
I don't think so... I have a feeling that's yet another weird oddity
to PHP parsing that's waiting to bite us in new and surprising ways.

-Sara

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

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

>>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, "value")`. It might be better to swap
> order, or change the method name, or add another method... Who knows? Need
> to take each case individually.

Having a separate method instead of `foo(null, "value")` makes it
difficult to use for the result of a function. Assume `bar()` returns
`Bar | Null`; this would no longer work if they were separated:

foo(bar(), "value")

Functions are often composed so if something is the output of one
function it will likely be the input to another. Thus if returning
optionally null values is important to you so should optionally null
parameters.

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

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

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 because it
>might be an easier vote?

Hi Richard,

That wasn't really my intent. I tried to set out my argument contra
nullable param type in the RFC and elaborate it in my answer to Levi,
which I hope you read.

My attitude to programming reversed since 10 years ago. I used to prefer
to have all the options and be allowed to exercise my judgement. But over
those years I had to remain responsible for most of my code, which led to
a blinding conversion. Now I am so acutely aware of how likely I am to
write bugs that I more often than not want the language to get smaller.

My sense is that nullable params won't turn out to be one of the good
parts, in the Crockford sense. Something|null return, otoh, is so
established as a convention I can't imagine getting away from it.

I'm aware that some people won't understand my point of view. If that's
still the case, ask again and I'll try a different answer.

Tom

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

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

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;
>$this->updateHeight();
>}
>
>Why disallow the explicit union with null here instead of the default
>parameter which does not exactly capture the desired semantics?
>Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
>I would much prefer `$node->setLeft(null)` here. Basically, if we have
>a feature for return types that exactly matches the semantics that we
>occasionally want for the parameter types why forbid it?

I agree that `$node->setLeft()` is weird but I find `$node->setLeft(null)`
still a bit weird. Perhaps something like `$node->resetLeft()` would work?
Was that the idea?

>Additionally, on occasion I'll see functions like this:
>
>function foo(Bar $b = null, $not_optional_param);

The only thing we can know for sure from this is that the programmer
urgently needs reeducation :)

>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, "value")`. It might be better to swap
order, or change the method name, or add another method... Who knows? Need
to take each case individually.

This kind of asking questions about intent in code review is good for code
quality. That's why I like how PHP doesn't allow this. It encourages the
question asking. Every case is different, of course, so you can surely
find counter examples. But on balance I'd say it's better to disallow it.

Does this help you understand my preference? I think the restriction
encourages a healthy discipline.

Otoh, I think nullable return is a pressing need.

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

2016-04-14 Thread Zeev Suraski



> -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...@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 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 instead?
> >>> :)
> >>
> >> A language that is usable primarily by beginners will only be useful
> >> for beginners.  Non-beginners will shun it, or simply grow out of it
> >> and leave.
> >>
> >> A language that is usable only by PhDs will be useful only for PhDs.
> >> Beginners won't be able to comprehend it.
> >>
> >> A language that is usable by both beginners and PhDs, and can scale a
> >> user from beginner to PhD within the same language, will be used by both.
> >>
> >> Doing that is really hard. And really awesome. And the direction PHP
> >> has been trending in recent years is in that direction.  Which is
> >> pretty danged awesome. :-)
> >
> >I would argue that PHP was already doing that almost since inception.
> >I think we have ample evidence that we've been seeing a lot of
> >different types of usage - both beginners' and ultra advanced going on
> >in PHP for decades.
> >I would also argue that in recent years, the trending direction has
> >been focusing on the "PhDs", while neglecting the simplicity seekers
> >(which I wouldn't necessarily call beginners).  Making PHP more and
> >more about being like yet-another-language, as opposed to one that
> >tries to come up with creative, simplified ways of solving problems.
> >Last, I'd argue that a language that tries to be everything for
> >everybody ends up being the "everything's and the kitchen sink", rather
> >than somethings that is truly suitable for everyone.
> >
> >We also seemed to have dumped some of our fundamental working
> >assumptions - that have made PHP extremely successful to begin with:
> >
> >- Emphasis on simplicity
> >- Adding optional features makes the language more complex regardless
> >of whether everyone uses them or not
> >
> >It does seem as if we're trying to replicate other languages,
> >relentlessly trying to "fix" PHP, which has been and still is one of
> >the most successful languages out there - typically a lot more so than
> >the languages we're trying to replicate.
> >
> >Zeev
> 
> 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 complicated things in a simple way, and not to do simple things in a
> complicated way.
> 
> 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 which have been made to PHP 5 simply because I can
> achieve what I need to achieve WITHOUT using any of those additions.
> 
> I will not be making use of any changes that are made to the language in order
> to handle typed variables for the simple reason that PHP was specifically
> designed to be an untyped language, and in the 13+ years that I have been
> programming with PHP I have found that to be more of an advantage than a
> hindrance.


Tony,

I think this is taking the discussion a bit in the wrong direction.

I, for one, certainly don't think that our problem is people who want to prove 
how clever they are, and I do believe that people who are proposing additions 
and improvements to the language are doing it because they think it's a good 
thing.  That does not mean it is though.

I am also saying that generally speaking, most people who are on internals@ are 
biased through self-selection towards change.  People who are just happy the 
way things are, are unlikely to be on internals and are unlikely to want to 
contribute.  Fixing bugs, meticulously optimizing performance while maintaining 
compatibility, these things get a LOT less interest and aren't main attraction 
points for joining internals.  Incidentally, they're also the things that the 
vast majority of users want the most.

As a whole, people don't realize that PHP does not need fixing.  I'm NOT saying 
it's perfect and that it cannot be improved - of course it can - but I am 
saying that it's not broken;  In fact, it's remarkably successful the way it 
is, and in fact, we have no evidence that since the RFC process was embraced 
and language-level features started making

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

2016-04-14 Thread Anatol Belski

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 NEWS file:

https://github.com/php/php-src/blob/php-7.0.6RC1/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.


Below is the verification information for the downloads:

php-7.0.6RC1.tar.bz2
SHA256 hash:
b62aebe7de4c065358ceef71592af6ff3b168ae8ac390dfa47295aca6bc9d74f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXDNalAAoJELyqMOqcDVdjpgIH/Rv5Wj09n9K0mX37lgBiR+85
cFPjxa/nlg6TrdM/f78zL/qV75Fnf1EhlKmJmObe8P2EUFszqcc8yz/NAAGi5KWr
77X9WKIDcy6tctofE8FBN6Tg0L6/IE5gF11pOCcLdLqOc711PkYefhWoKiuqNv8L
EmMY6PIq2FY8TtjL3EW8UNUOy39FTDus3llQkB55xRMriSIpbnDLnOcAxgp8hIXJ
8VGh3yfatFnkK9Pzo/oGAQWFq6K1YI0L28/0Dfd4kM58U4ByeOD+q5M6Hg6a6pVR
Y3zrnkW5h4JIFFuijKL4P3c6fTnrvTezNXZFx04l/n/QxI1lQXO20Kpyeb8CPqQ=
=mzht
-END PGP SIGNATURE-


php-7.0.6RC1.tar.gz
SHA256 hash:
06842e23cf17a23b19ded17e8271ea0d6974cf721d43baceadf6f6f88a5dfd72
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXDNaoAAoJELyqMOqcDVdjPJ4IAKSvASjYbMMM0ix7A/U7eyrP
lhxgjJcYFJvhYtLP5jcTXKzC1iD3DVbxoIqZXfXD4S10z2cgohIJYjuJwYY5uVHx
/Hc5JpCiABHia5EGd2Uj++7KZpH1nlZrZZ0RTZrfN3YRZG6/SzRXAOxeh/SKboU7
Bg6nwwI27vO4g6Nn4k/ZpCW9HdX2AlAWn8/pSC1b4l9WWJk2+45qM72NmHyASuNh
m44slCLNSnM/I28szima8iReOnQJMb/hSkz7ORYwU6UvH0QYfK3wMVzrQW76ATcl
CqUcKATQK6xNrMvGlDGMB7ouqwtElQOpjp7dKmwNZaiGj9bZfCBUhdxJxaTtZwM=
=V9Qy
-END PGP SIGNATURE-


php-7.0.6RC1.tar.xz
SHA256 hash:
c6de3dc8cbda5ca65cb9ddf846cbe451663cb96522ca4d9fed09cae78b03905c
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXDNaqAAoJELyqMOqcDVdjS/sIAIzKFoe7q82sieH5eFpjm5mI
Zq9iqKdr2OMu5b5L5AwEbKU118YmG1Ggd4XMo6ResGKrwgDW8ccdFrXBBrMJNDoz
ngf50Ca3FaWgcGvsdTQpnV/JXlp3NmZFPwHk+2V0TmI8DAbnnX+XIPTwZXcXrdxY
ga4V+++cYleCjaOPtxDZ+Fs/SqLel7M0EgZ0yRrYUzOmjUHW28ipcEocvitMogKH
oALPthqj3opVQJG/a+aI8AzRISYhKr0gUMGs4VcqJa1PbDO0nv4nthF8w5fWYx65
VhgdCgB4lCCgRrNby7hodKjKK8kaNYeXx9Ei7PmRB/oeT6PLfq87h12lgqjwjHY=
=nEUv
-END PGP SIGNATURE-

Thank you for your support.

Anatol Belski and Ferenc Kovacs


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

2016-04-14 Thread Stanislav Malyshev

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
> *float|string* for overflows as one can encounter them from time to
> time; even in native code.

Not sure what are you referring here to, but I suspect you are trying to
reimplement weak typing in some partial inconsistent and strange way,
while pretending it's strong typing.

-- 
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: Typed properties patch

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, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();

We also have specialized handlers that don't check for types at all (they are 
used, if we know types at optimization time).

ZEND_VM_TYPE_SPEC_HANDLER(ZEND_ADD, (res_info == MAY_BE_LONG && op1_info == 
MAY_BE_LONG && op2_info == MAY_BE_LONG), ZEND_ADD_LONG_NO_OVERFLOW, 
CONST|TMPVARCV, CONST|TMPVARCV, SPEC(NO_CONST_CONST,COMMUTATIVE))
{
USE_OPLINE
zval *op1, *op2, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
result = EX_VAR(opline->result.var);
ZVAL_LONG(result, Z_LVAL_P(op1) + Z_LVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}

The second technique won't work for typed properties if they might be turned 
into IS_UNDEF. 

Thanks. Dmitry. 


From: Stanislav Malyshev 
Sent: Thursday, April 14, 2016 20:26
To: Dmitry Stogov; Joe Watkins
Cc: internals; Zeev Suraski; Nikita Popov
Subject: Re: [PHP-DEV] Re: Typed properties patch

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 will have to check for IS_LONG
> anyway.

Well, we'd have to check for IS_UNDEF, but we won't have to choose
between IS_LONG, IS_OBJECT and IS_RESOURCE.

> So type hinting won't improve reading performance, but writing is going
> to be slower, because we have to perform type check.
> So even theoretically this approach couldn't make any improvement.

Maybe I misunderstand what performance improvements there are. Do we do
different things when reading a variable depending on type? I thought
it's for *operations* with variables, but for just reading them it
doesn't matter. For operations, we could have instead of function
handling all types just function handling IS_LONG and a small check for
UNDEF inside.

I think it is mych better than a weird concept of non-unsettable variable.
--
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

2016-04-14 Thread Jordi Boggiano

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

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.

That said I agree it's rarely useful, and as such I am not expecting
we'll see this all over the place, it's just nice to have when you need
it, but I can't think of very many valid cases (nullable types are much
more common).

Please take that into consideration as well when arguing that it adds
complexity. If it's rarely seen in the wild it's not very valuable but
it's *also* not hindering newcomers often.

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.

Just to highlight one use case I can think of, here is one:

https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/MongoDBHandler.php#L51-L53

We need some sort of Mongo thing, and there are two available with
different interfaces, so here both are accepted but as you see in the
code below they are handled kinda separately. It would just save us
those 3 lines of check if we could type-hint appropriately.

And it would save us one line of phpdoc as well because IDEs could infer
the information from the code.

Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

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

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'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.
>>
> 
> Reduce assertions*, enhance self-documentation, making code more robust,
> perform checks in the VM and not in userland, ...
> 
> function fn($arg) {
> assert('is_string($arg) || method_exists($arg, "__toString")');
> }
> 
> interface Stringable {
> function __toString(): string;
> }
> 
> function fn(string|Stringable $arg) {
> // :)
> }
> 
> You can find more information on the topic here:
> 
> https://en.wikipedia.org/wiki/Tagged_union
> 
> * Assertions in PHP are very error prone if combined with refactoring
> due to the fact that one should enclose the actual assertion in a string.
> 

Oh oh oh, I forgot the very important unions *int|string* and
*float|string* for overflows as one can encounter them from time to
time; even in native code.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

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

Reduce assertions*, enhance self-documentation, making code more robust,
perform checks in the VM and not in userland, ...

function fn($arg) {
assert('is_string($arg) || method_exists($arg, "__toString")');
}

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
// :)
}

You can find more information on the topic here:

https://en.wikipedia.org/wiki/Tagged_union

* Assertions in PHP are very error prone if combined with refactoring
due to the fact that one should enclose the actual assertion in a string.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

2016-04-14 Thread Stanislav Malyshev

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

> docs (IDE or online) in which order I need to pass arguments to one of
> the various mixed up functions in the core all the time.

Which takes about 0.5 seconds. Can we please not waste time on
discussing argument order some 9000th time?

> PHP is not easy, it has so many quirks that one needs to know of that
> you could make a PhD only for that.

PHP has some quirks, but it doesn't take PhD to look up argument order
in a manual. Anyway, having super-complicated type algebra does not help
any with argument order, so I'm not sure why it's brought here at all.

> https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> 
> This contains A LOT of that stuff.

Oh, could we please stop referring to this list of nitpicks each time we
discuss the language? About 90% of it is not worth the bytes spent on it
for discussing it again and again. Using it as some kind of magic "some
guy wrote article bashing PHP, therefore my proposals need to be
accepted" card makes no sense at all.

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

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 something to check whether if they write the correct
> code.
> 
> And I believe, if we can remove the support of weak type conversion, PHP
> could be a "consistent", "simple" language and it can help people write
> confident code.
> 

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
docs (IDE or online) in which order I need to pass arguments to one of
the various mixed up functions in the core all the time.

PHP is not easy, it has so many quirks that one needs to know of that
you could make a PhD only for that.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

This contains A LOT of that stuff.

-- 
Richard "Fleshgrinder" Fussenegger

signature.asc
Description: OpenPGP digital signature

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

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

I have to agree with the question mark in front after reading the
possible problems with the question mark as a suffix, the fact that HHVM
already puts it in front, and the argument to read it as "nullable type"
instead of "type or null". :)

+1

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

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's two RFCs.
>>
>>   https://wiki.php.net/rfc/nullable_returns
>>
>> If anyone would like to collaborate on the RFC, I have a repo you may fork:
>> https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
>> formatting isn't lovely). I'm looking for help with implementation.
>>
>> Tom
>>
>>
>>
> 
> 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;
> $this->updateHeight();
> }
> 
> Why disallow the explicit union with null here instead of the default
> parameter which does not exactly capture the desired semantics?
> Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
> I would much prefer `$node->setLeft(null)` here. Basically, if we have
> a feature for return types that exactly matches the semantics that we
> occasionally want for the parameter types why forbid it?
> 
> Additionally, on occasion I'll see functions like this:
> 
> function foo(Bar $b = null, $not_optional_param);
> 
> 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.
> 

My guess is that this RFC only wants to get it for return because it
might be an easier vote?

I do not like the fact that only the long version of union types is
supported and prefer the question mark approach as a short hand. Can
this RFC be either extended to include that as well or removed so it
does not get in the way of the other two RFCs?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

2016-04-14 Thread Stanislav Malyshev

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 will have to check for IS_LONG
> anyway.

Well, we'd have to check for IS_UNDEF, but we won't have to choose
between IS_LONG, IS_OBJECT and IS_RESOURCE.

> So type hinting won't improve reading performance, but writing is going
> to be slower, because we have to perform type check.
> So even theoretically this approach couldn't make any improvement.

Maybe I misunderstand what performance improvements there are. Do we do
different things when reading a variable depending on type? I thought
it's for *operations* with variables, but for just reading them it
doesn't matter. For operations, we could have instead of function
handling all types just function handling IS_LONG and a small check for
UNDEF inside.

I think it is mych better than a weird concept of non-unsettable variable.
-- 
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] Nullable Return Type Declaration

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/nullable_returns
>
> If anyone would like to collaborate on the RFC, I have a repo you may fork:
> https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
> formatting isn't lovely). I'm looking for help with implementation.
>
> Tom
>
>
>

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;
$this->updateHeight();
}

Why disallow the explicit union with null here instead of the default
parameter which does not exactly capture the desired semantics?
Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
I would much prefer `$node->setLeft(null)` here. Basically, if we have
a feature for return types that exactly matches the semantics that we
occasionally want for the parameter types why forbid it?

Additionally, on occasion I'll see functions like this:

function foo(Bar $b = null, $not_optional_param);

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.

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

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


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 meaningful discussion!

   [1]: http://news.php.net/php.internals/92252
   [2]: https://wiki.php.net/rfc/union_types


Hi Levi,

Your email [1] excellently summarizes the overall historical and present 
context. In it you listed three specific things that 7.0 cannot 
represent. My RFC[3] basically argues in favor of implementing only the 
first of these in 7.1. I like to see this as a more conservative version 
of yours, preferring a more gradual introduction of these three 
loosenings of PHP 7.0's type features.


[3] https://wiki.php.net/rfc/nullable_returns

I hope you will consider this a constructive contribution to the discussion.

Tom


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

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

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, I have a repo you may fork:
https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
formatting isn't lovely). I'm looking for help with implementation.

Tom

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

> 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 custom types and
> using them instead.
>
> I very much like Hacks type/newtype stuff, if we extended that to support
> union types:
>
> newtype Numeric = int|float;
>
> Then you end up with simply: ?Numeric as your type (it should be
> namespaced).
>
> You could further expand that with casting rules:
>
> newtype Numeric = int|float {
>   string as float;
>   bool as int;
> }
>
> or even go so far as:
>
> newtype Numeric = function($value): int|float {
>  if ($value typeof int) {
>  return $value;
>  }
>
> return (float) $value;
> }
>
> FTR: I hate that last one, just spitballing.
>
> - Davey
>
> P.S.
> if someone is willing to tackle the code for custom types I'm willing to
> write an RFC

This issue is addressed partially in the future scope section of the
RFC: https://wiki.php.net/rfc/union_types#long_type_expressions.

If both nullable and full union types are allowed I was planning on
disallowing the short-hand notation when using unions. As it isn't
that relevant at this stage it isn't noted in the RFCs anywhere.

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

> 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: http://www.php.net/unsub.php

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

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 several enumerated
>> types. For example, this is a potential signature for a multi-type map
>> routine:
>>
>> function map(callable $f, Array | Traversable $iterable);
>
> 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:

This is not missing in the RFC; see the section called Weak Scalar
Types in Open Issues. However, it does not propose a solution. I have
been assured by a few people that it is possible and it is just
something that needs worked out.

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

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. The aim of any language should be to
> > enable programmers to do complicated things in a simple way, and not
> > to do simple things in a complicated way.
>
> I disagree. My way of looking at it is that adding some features(eg the
> current
> type specification/checking) adds to the simplicity because I can say what
> types
> I want and don't need to write code to check the types of argument
> received by a
> function (etc).

Why would I want to check: because I value robustness, ie not having my code
> fall over because, somehow, a wrong type slips by unnoticed.

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.

Haskell, OCaml, C or C++, these statically typed languages compile code
into executable binary, the compiler raises the warnings or errors before
executing it, thus they have more time to check type information, they
usually don't check type in the run-time.

However PHP is not, PHP runs script on the fly, and check the type in the
runtime (instead of compile time), therefore the type checking implemented
in PHP is a kind of execution performance trade off (until we implemented
the JIT compiler). and a complex type system add more extra work to the
whole system than statically typed language.

Adding type hinting makes people writing PHP code with more confident, I
like the scalar type hinting implemented in the current PHP.

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 something to check whether if they write the correct
code.

And I believe, if we can remove the support of weak type conversion, PHP
could be a "consistent", "simple" language and it can help people write
confident code.

Cheers, Yo-An Lin

Re: [PHP-DEV] IntlCharsetDetector


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. We should
not ignore that.


Well, Stas, your informal thumbs up to the idea means enough to me to
at least formalize it into an RFC even though I was previously feeling
negative on it.

I may yet vote no on my own RFC after the discussion period, but as
you say it's worth considering the fact that someone thought it
reasonable enough to actually build into ICU...


The general problem is impossible. If you constrain the question, for 
example as Stas says by knowing the language and choosing between a 
given set of codes, then you may have success. And I'm sure I'm not 
alone in sometimes using a simple heuristic to choose between cp1252 and 
utf8.


But this does not logically imply that ICU CharsetDetector is a suitable 
solution in such cases or that it's a good API or a decent 
implementation. Or that PHP should expose it. An SO chat doesn't 
necessarily count as a feature request.


I'd rather people engineered real solutions specific to their 
requirements than resort to any of the failed attempts to solve the 
general problem.


Tom


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

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

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 variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.


>
Does Hack support weak type conversion?




-- 
Sent from Gmail Mobile

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

2016-04-14 Thread lp_benchmark_robot

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
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.21% -0.21%  0.84%  
  7.00%
:-|   Drupal 7.36 cgi -T1  0.15%  0.59% -0.08%  
  4.22%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16%  0.09%  1.62%  
  2.98%
:-|   bench.php cgi -T100  0.01%  0.01% 23.77%  
  2.00%
:-|  micro_bench.php cgi -T10  0.01%  0.01%  5.88%  
  3.66%
:-|  mandelbrot.php cgi -T100  0.07%  0.21% 28.91%  
  9.57%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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: New RFC draft "static class constructor"

2016-04-14 Thread S.A.N

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 it.
>>
>> As I already mentioned in the prediscussion thread here:
>>
>> For being my first change to the PHP core, I would be very happy, if
>> someone of the "old stager" would help me with the implementation of
>> this RFC if it is accepted.
>>
>> Regards
>>
>
> Hi there,
>
> there was a really bad situation in my life the last week, so I'm not
> able to do anything on this Draft for some days, I will pause it for
> some weeks now
>
> Regards
>
> --
> DerOetzi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hi.

Is any progress on the implementation?

Thank.

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

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

2016-04-14 Thread Davey Shafik

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]" does not evaluate to $foo['my'] but to $foo['great'].

- Davey

On Tue, Apr 12, 2016 at 8:08 PM, Sara Golemon  wrote:

> I'm trying to decide just whether or not
> https://bugs.php.net/bug.php?id=71927 is "working as intended" as well
> as what the expected behavior in this situation /should/ be.
>
> https://3v4l.org/HfU1g indicates that at the very least HHVM and PHP
> disagree on the correct output, and testing the same sort of
> expression in bash says that it's not having any of it; "invalid
> substitution" warnings abound.
>
> The PHP behavior is just kinda weird.  "${ great}" does constant
> interpolation yielding "$my" which in turn becomes variable
> interpolation and we find up with "my value".  I'm actually doubtful
> that PHP pulls off this juggling *by accident*, which is why I'm
> posting about it before even going to the extent of proposing an RFC.
>
> Does anyone have historical context on this and can explain the
> current behavior as "working as intended"?
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

2016-04-14 Thread Davey Shafik

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 simply
casting to the first type always, or we're going to have to come up with
some potential complex rules.

For example, what if you have: int|float, and pass in (string) "0.5", if
those were separate types you'd get (int) 1, or (float) 0.5 respectively,
and as a user I'd definitely expect it to be passed in as (float) 0.5 —
maybe we cast to the least lossy type? So if you have int|float, then a
numeric string always becomes a float.

The flip-side is that if we just decide first-always then it's up to the
developer to just define it as "float|int" instead.

I think Derick has definitely hit upon the trickiest part of this.

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 custom types and
using them instead.

I very much like Hacks type/newtype stuff, if we extended that to support
union types:

newtype Numeric = int|float;

Then you end up with simply: ?Numeric as your type (it should be
namespaced).

You could further expand that with casting rules:

newtype Numeric = int|float {
  string as float;
  bool as int;
}

or even go so far as:

newtype Numeric = function($value): int|float {
 if ($value typeof int) {
 return $value;
 }

return (float) $value;
}

FTR: I hate that last one, just spitballing.

- Davey

P.S.
if someone is willing to tackle the code for custom types I'm willing to
write an RFC

On Thu, Apr 14, 2016 at 2:25 AM, Derick Rethans  wrote:

> 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|bool $var) { echo get_type( $var ), "\n"; }
> > >
> > > foo(5); I guess int(5)
> > > foo(false); I guess bool(false)
> > > foo(0.5);   It could be either int(1) or bool(true)
> > >
> > > And what if the hint would be "bool|int" ?
> >
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

2016-04-14 Thread Matt Prelude




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

Please put it where HHVM puts it: in front of it. Other languages are
less of an issue than a syntax that's already used in a somewhat PHP
language.

As to the rest of the RFC: LGTM!


I much prefer the "Nullable Foo" (?Foo) to "Foo or Null"  (Foo?). I find it
easier to read.

However, I am not a fan of introducing both this and the "Null" type for
union types — this should be the only way to create nullable types. We
already have too many things that are possible in more than one way.

As it sits, this is purely syntactic sugar (when taken in tandem with union
types) and [if] we agree that it is good, then let us just forgo the other
syntax entirely. I'll add a little about that on the appropriate thread.

- Davey

Also agree, the "nullable foo" reads better and has the advantage of 
compatibility
with HHVM. The easier we make it for people to switch interpreters (and 
develop

software which works on both interpreters) the better for PHP as a whole.

Also agree that we don't need null union types if we have nullable types.

- Matt


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

2016-04-14 Thread Lester Caine

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 which have been made to PHP 5 simply
> because I can achieve what I need to achieve WITHOUT using any of those
> additions.

+1
I certainly wish I'd stopped at PHP5.2 and simply maintained a safe copy
of that.

-- 
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] Nullable Types

2016-04-14 Thread Davey Shafik

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 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].
>
> Please put it where HHVM puts it: in front of it. Other languages are
> less of an issue than a syntax that's already used in a somewhat PHP
> language.
>
> As to the rest of the RFC: LGTM!

I much prefer the "Nullable Foo" (?Foo) to "Foo or Null"  (Foo?). I find it
easier to read.

However, I am not a fan of introducing both this and the "Null" type for
union types — this should be the only way to create nullable types. We
already have too many things that are possible in more than one way.

As it sits, this is purely syntactic sugar (when taken in tandem with union
types) and [if] we agree that it is good, then let us just forgo the other
syntax entirely. I'll add a little about that on the appropriate thread.

- Davey

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

2016-04-14 Thread Lester Caine

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 instead? :)

Well it's well above my M.Sc in Digital Systems ... but that was gained
in 1982 and it seems even my wife's primary school charges are already
trained to a higher level of programming.

-- 
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] Final properties

2016-04-14 Thread Lester Caine

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 be a floating point number while others will
be working with a 32bit or 64bit integer. Simply adding a 'type' to this
traditional property does not address a number of potential bugs in
using 'Seconds' as a simple variable.

'Hours' is now an object in it's own right, so how is it really any
different to 'TimePeriod' it is essentially a class with a set of
associated functions, and all of baggage to make it work. 'Final' is
just another function to be added to the 'Hours' object?

I keep banging on about this, but in addition to 'Final', set, get,
isset, unset, and all of the trait/reflection functions to
define/inspect why would you not expect facilities also to validate the
range of a number, it's accuracy limits if a float, and the sizes of the
object if it's a string? The second you move beyond the basic variable
as found in PHP4 have you not simply upgraded to an object and all the
baggage that is essential to make that work. Even 'null' is simply a
state that the object takes since it's not something that can be
assigned as a value in the 'register' that is being used to store it's
value?

I don't see how the idea of 'optimizing' the compiled code has any
bearing on handling a 'typed property' when one has to have an object to
contain even the simple of type information?

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

2016-04-14 Thread Alain Williams

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 complicated things in a simple way, and not
> to do simple things in a complicated way.

I disagree. My way of looking at it is that adding some features(eg the current
type specification/checking) adds to the simplicity because I can say what types
I want and don't need to write code to check the types of argument received by a
function (etc).

Why would I want to check: because I value robustness, ie not having my code
fall over because, somehow, a wrong type slips by unnoticed.

Does that make quick/simple programming not possible in PHP ?

No: I will put the most of the robustness work into libraries/classes that I
write and want to reuse - the simple programs that use them don't necessarily be
written to the same standard.

> 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 which have been
> made to PHP 5 simply because I can achieve what I need to achieve
> WITHOUT using any of those additions.
> 
> I will not be making use of any changes that are made to the
> language in order to handle typed variables for the simple reason
> that PHP was specifically designed to be an untyped language, and in
> the 13+ years that I have been programming with PHP I have found
> that to be more of an advantage than a hindrance.

Type juggling is useful, but somewhere you do need to check your input.

I doubt that we will agree, but we don't need to: we prob have different aims
and goals. There is no reason that PHP cannot satisfy both of us.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include 

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

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

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|bool $var) { echo get_type( $var ), "\n"; }
> >
> > foo(5); I guess int(5)
> > foo(false); I guess bool(false)
> > foo(0.5);   It could be either int(1) or bool(true)
> >
> > And what if the hint would be "bool|int" ?
> 
> I think type conversion shouldn't be done internally, implicitly.
> 
> Implicit conversion leads more confusion in the language. when you 
> pass variables, you have to remember these conversion rules.

Sorry, we already have this with our weak scalar types. You can't make 
union types not work with that.

cheers,
Derick

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

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

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); I guess int(5)
> foo(false); I guess bool(false)
> foo(0.5);   It could be either int(1) or bool(true)
>
> And what if the hint would be "bool|int" ?
>

I think type conversion shouldn't be done internally, implicitly.

Implicit conversion leads more confusion in the language. when you pass
variables, you have to remember these conversion rules.

type conversion should be done in the caller, that's why typed language
like C or C++ ask you to convert the type manually before you pass the
variable into a function.

-- 
Best Regards,

Yo-An Lin

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

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 signature for a multi-type map
> routine:
> 
> function map(callable $f, Array | Traversable $iterable);

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); I guess int(5)
foo(false); I guess bool(false)
foo(0.5);   It could be either int(1) or bool(true)

And what if the hint would be "bool|int" ?

Although it's probably easy enough to solve in this case, the RFC should 
detail how type conversion works with the scalar types.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] IntlCharsetDetector

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 discussion period at least.

The RFC itself looks fine. I still believe that it's 
too easy to just rely on the charset that it returns. I know there is a 
confidence factor, but you know how lazy we are :). Unless it's 
absolutely clear that it is merely a very badly educated guess, I think 
I shall be voting no.

cheers,
Derick

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

2016-04-14 Thread Tony Marston

"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 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 instead? 
:)


A language that is usable primarily by beginners will only be useful for 
beginners.  Non-beginners will shun it, or simply grow out of it and 
leave.


A language that is usable only by PhDs will be useful only for PhDs. 
Beginners won't be able to comprehend it.


A language that is usable by both beginners and PhDs, and can scale a 
user from beginner to PhD within the same language, will be used by both.


Doing that is really hard. And really awesome. And the direction PHP has 
been trending in recent years is in that direction.  Which is pretty 
danged awesome. :-)


I would argue that PHP was already doing that almost since inception.  I 
think we have ample evidence that we've been seeing a lot of different 
types of usage - both beginners' and ultra advanced going on in PHP for 
decades.
I would also argue that in recent years, the trending direction has been 
focusing on the "PhDs", while neglecting the simplicity seekers (which I 
wouldn't necessarily call beginners).  Making PHP more and more about being 
like yet-another-language, as opposed to one that tries to come up with 
creative, simplified ways of solving problems.
Last, I'd argue that a language that tries to be everything for everybody 
ends up being the "everything's and the kitchen sink", rather than 
somethings that is truly suitable for everyone.


We also seemed to have dumped some of our fundamental working assumptions - 
that have made PHP extremely successful to begin with:


- Emphasis on simplicity
- Adding optional features makes the language more complex regardless of 
whether everyone uses them or not


It does seem as if we're trying to replicate other languages, relentlessly 
trying to "fix" PHP, which has been and still is one of the most successful 
languages out there - typically a lot more so than the languages we're 
trying to replicate.


Zeev


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 complicated things in a simple way, and not to do simple things in a 
complicated way.


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 which have been made to PHP 5 simply because I can 
achieve what I need to achieve WITHOUT using any of those additions.


I will not be making use of any changes that are made to the language in 
order to handle typed variables for the simple reason that PHP was 
specifically designed to be an untyped language, and in the 13+ years that I 
have been programming with PHP I have found that to be more of an advantage 
than a hindrance.


--
Tony Marston


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

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

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

Please put it where HHVM puts it: in front of it. Other languages are 
less of an issue than a syntax that's already used in a somewhat PHP 
language.

As to the rest of the RFC: LGTM!

cheers,
Derick

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

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

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)
>
> Support for multiple classes would lead to complex implementation.
>
> Thanks. Dmitry.
>
> 
> From: Levi Morrison >
> Sent: Thursday, April 14, 2016 06:46
> To: internals
> Subject: [PHP-DEV] [RFC] Union Types
>
> 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 signature for a multi-type map
> routine:
>
> function map(callable $f, Array | Traversable $iterable);
>
> The second parameter `$iterable` is required to be of type Array or
> Traversable - any other type will error.
>
> I look forward to a helpful and meaningful discussion!
>
>   [1]: http://news.php.net/php.internals/92252
>   [2]: https://wiki.php.net/rfc/union_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Sent from Gmail Mobile

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




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 we keep a class definition, where the type of property "$a" - 
IS_LONG, but the actual value of "$a" may become IS_UNDEF.



x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use
optimized code */

Can't we assume $a->x is still "int" here in a way - I mean, we'd still
have to allow for the possibility of null, but if we say that any one
could be null it's just one easy check, so it won't hurt performance too
much, not?

In PHP-7 we check for IS_LONG without type hint.
With type hint and ability to unset(), we will have to check for IS_LONG 
anyway.
So type hinting won't improve reading performance, but writing is going 
to be slower, because we have to perform type check.

So even theoretically this approach couldn't make any improvement.

Thanks. Dmitry.







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

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

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
Subject: [PHP-DEV] [RFC] Union Types

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 signature for a multi-type map
routine:

function map(callable $f, Array | Traversable $iterable);

The second parameter `$iterable` is required to be of type Array or
Traversable - any other type will error.

I look forward to a helpful and meaningful discussion!

  [1]: http://news.php.net/php.internals/92252
  [2]: https://wiki.php.net/rfc/union_types

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


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

Re: [PHP-DEV] Final properties

2016-04-14 Thread André Rømcke




> 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 like Property Accessors 
Syntax* is re opened and updated?

>From user land main motivation to support this and typed properties is to be 
>allowed to type hint and make properties readonly to simplify use cases for 
>entities and value objects, using properties, and not having to resort to 
>magic methods which tends to become slow(er) and messy. For how this is 
>archived, not violating LSP, and making sure the language and internals are 
>kept as consistent as possible would be high up there as reasoning to pick 
>approach



* https://wiki.php.net/rfc/propertygetsetsyntax-v1.2


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

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