[PHP-DEV] [RFC] Union Types

[Levi Morrison]

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-DEV] [RFC] Nullable Types

[Levi Morrison]

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

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

[Zeev Suraski]

> 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

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

Re: [PHP-DEV] Final properties

[Stanislav Malyshev]

Hi!

> var class ?!?
> var function ?!?
> var const ?!?
> var static ?!?

Ah, of course not. "var" is for vars.

> I did not say that a userland developer should care I only stated that
> it is one difference between a constant and a final property. ;)

This is not a difference that is important.

> This thread is meant to find out where, how, when support is needed and
> you are absolutely right that *__wakeup* needs support too. I am sure we
> overlooked others yet. I did not claim to cover all edge cases. ;)

Part of my point is that covering the edges would be hard, because you
are trying to introduce something that is not aligned with how the
language is (or was) supposed to work, and thus require a lot of special
cases. This is a sure recipe for trouble - once you rely on
special-casing, you are guaranteed to forget some. KISS was not
proclaimed a principle just because people are lazy and avoid work.

> That is exactly the point of it. Limiting interaction, limiting sources
> of bugs. Just read why others want to have them instead of only taking
> my word (and bad examples) for it.

But it's not limiting - you can not even refactor methods, so you'd have
to copy-paste same code in several methods, with all bugs that follow.
And of course you'd frequently forget to account for all places where
magic should happen and get objects behaving in weird ways. This does
not sound good.

I can see a case between splitting read and write on class boundary -
internal implementation can write, but outside can only read. In fact,
this pattern is already widely implemented. I can see why you may want
to get rid of this pattern of having interface/getter and instead have a
pattern of public variables - but for this you'd need property
interfaces first, and even then it would be unclear - how exactly the
interface would specify readonly variable? Would you be allowed to
extend it with r/w variable (I can give you equally sound arguments for
"yes" and "no" here, depending on use case)?

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.

It also seems to me like the main reason to do this is to exactly mimick
behavior of "final" properties in Java - which is not a very worthy goal
by itself.

> It is an example to illustrate the functionality and not meant to be a
> blueprint for all userland implementations that are yet to be written
> till the end of time. It is contrived, no argument there.

The problem is not that it's contrived, the problem is that it shows not
why you need it but rather why you don't need it :) You are welcome to
provide better example/use case, of course, but so far it looks to me
like protected/getter works just fine. At the cost of a function call,
of course, but see above why it may be preferable.

> Because you want to let child classes read from the property without
> calling methods while making sure that they cannot change it in any way
> (also called *readonly* in C#). This is particularly important in case

You can always have private/protected as boundary instead of
protected/public, that doesn't change much. Saving a function call looks
like premature optimization here.

> of object getters because a child class cannot trust the parent class
> that an object retrieved from that getter is always the same instance.

Not sure what you mean here. If the API allows to return different
instances, then you get different instances. What's the problem here?

> With a *final val* property the child can trust the parent again. I know

This looks like wrong design approach - you are trying to put knowledge
on the client that does not belong there - such as how many instances of
value object exist and how they are managed. For value objects this
looks wrong - if it's a value, it shouldn't matter which instance of it
you are getting. If it's a mutable stateful object and not a value
object, it's worse - you can't then know who messed with that object
before and what is there now, so final doesn't help much.

> I know that it might look like that but I still think that its usage is
> ambiguous and inconsistent and all explanation attempts failed in the

Ambiguous between what and what? If you see "var $foo", which two
options you can not distinguish? How it is inconsistent? I think we need
to stop using "inconsistent" when that is meant is "I do not like it".
"var" is perfectly consistent and means always the same thing. There's
better named alternative for it, true, and you're free to use that if
you like. That's it.

> Really? You should look at *final*, *val*, and *var* -- what are we
> discussing here?

"final" in Java is used in a lot of senses. Some of them would make
sense in PHP, some not. For some cases, "final" doesn't actually provide
much value - e.g. assigning a mutable object to a final variable, since
it does not guarantee you anything really except 

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

[Larry Garfield]

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


--
--Larry Garfield


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

Re: [PHP-DEV] Final properties

[Fleshgrinder]

On 4/13/2016 10:18 PM, Stanislav Malyshev wrote:
> How exactly it isn't? Except for "static"/"const" thing (which is really
> a parser glitch and could be easily fixed if anybody cared) I don't see
> a difference. Pretending like that static/const thing is a serious issue
> that warrants some deep changes makes no sense to me - it's just a very
> minor bug.
> 

Possible approach, yes. Still a huge inconsistency with function
declarations and their access modifiers (*var function*?!?). Just look
at the special definitions in the Bison file on how it is currently
handled. I know that the two of us have a different meaning about this
topic but in case we extend access modifiers inconsistency grows.

var class ?!?
var function ?!?
var const ?!?
var static ?!?

>> It is different to a constant in many ways:
>>
>> - It is bound to the instance and GCed with it.
> 
> Don't see why is it good or why should I care.For all I care it may
> never be GCed at all (such as interned strings), and userland developer
> should not be worrying about these details anyway.
> 

I did not say that a userland developer should care I only stated that
it is one difference between a constant and a final property. ;)

>> - It can be set in the constructor.
>> - It can be cloned in __clone.
> 
> I find the idea that you have special methods that have magic about
> variables not available to other methods rather unwise. And, you forgot
> __wakeup for example, unless you're not going to ever serialize your
> value object. And maybe other use cases. The point is, you are building
> very complex mechanism here that is too magic, and it is going to break
> in weird ways because it doesn't work like the rest of language works.
> 

This thread is meant to find out where, how, when support is needed and
you are absolutely right that *__wakeup* needs support too. I am sure we
overlooked others yet. I did not claim to cover all edge cases. ;)

> It also promotes bad design, as unless you want to track stack traces,
> you'd be able to touch these vars only in magic methods, thus requiring
> placing the code dealing with these vars in each of those methods and
> only there - you can't put this code in a different method, for example,
> because that method won't be magic. So, no refactoring for magic methods.
> 

That is exactly the point of it. Limiting interaction, limiting sources
of bugs. Just read why others want to have them instead of only taking
my word (and bad examples) for it.

>> public function update(): void {
>> $this->changed = new DateTimeImmutable;
>> }
> 
> I don't see how $created works better than $changed. Moreover, it looks
> rather strange that you have getter for $changed but not for $created.
> To achieve consistency and avoid confusing people, you probably would
> also have getCreated() anyway - which then makes "val" completely redundant.
> 

It is an example to illustrate the functionality and not meant to be a
blueprint for all userland implementations that are yet to be written
till the end of time. It is contrived, no argument there.

>> To avoid that child classes change the signature of a property from a
>> parent class if that is not desired. This is especially useful if you
>> intend to use public properties as part of your API or simply want to
> 
> I think that's not how it is done by all code I've seen so far - they
> use getters instead. Now, we can say we want to get rid of getters, but
> then I still don't see what use case final serves. I mean, "final is to
> make things unchangeable" is not a use case - it just restating the same
> thing in different words. The real question is *why* you need to make
> them unchangeable?
> 

Because you want to let child classes read from the property without
calling methods while making sure that they cannot change it in any way
(also called *readonly* in C#). This is particularly important in case
of object getters because a child class cannot trust the parent class
that an object retrieved from that getter is always the same instance.
This is why it is recommended to assign the result of such a call in a
method in various highly regarded literature (e.g. Steve McConnell Code
Complete comes to my mind).

With a *final val* property the child can trust the parent again. I know
that the situation is often different in PHP because the source is
always readily available. However, an API user should not need to dig
into the source code, an API user should be able to understand, use, and
trust other code simply through peeking at definitions and signatures.
Before you start, I am not claiming that this is always possible nor
that this is always desired, always needs to be like that, or anything
else. It is just something that is nice to achieve and it allows control
over what is going to happen at runtime and how people will be able to
interact with code that was written by you for them.

>> I am not saying that public properties should be part of 

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

[Stanislav Malyshev]

Hi!

> Types are designed in a way enhancing the languages experience while
> avoiding nearly every impact for people who want to ignore them.

This is not true. If it's in language, you have to understand it to be
able to use the language. Nobody writes code in vacuum - there are
libraries, communities, teams, best practices, tutorials, etc. So if
(hypothetically) you want to introduce algebraic types in PHP, then
since that moment you can not really be a PHP programmer if you don't
understand algebraic types. Otherwise you would not be able to
communicate with the rest of the community, understand and use code
written by others, contribute to projects, etc.

> And that's why we shall continue on improving our *optional* type
> system.

That's a very broad statement which which everybody agrees - who's
against improving? Who'd want to make the type system *worse*? Nobody.
The specifics are more complicated - do we really need complex type
expressions in PHP to the point of inventing micro-language with its own
syntax to just specify a type? I don't think so.

-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Bob Weinand]

> Am 13.04.2016 um 22:24 schrieb Stanislav Malyshev :
> 
> 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? :)
> -- 
> Stas Malyshev
> smalys...@gmail.com

PHP has and will retain the invaluable capability of not requiring types.

If you have weak types, which you have by default, it's just about as easy as 
it was the last 15 years.
The only thing which changed is that not only internal functions but also user 
functions can impose some limits on what is being accepted. I could understand 
your complains if it were completely new and not even internal functions ever 
rejected inputs based on types [or rather how well-formed numeric strings they 
are].

The only thing a bit harder (requiring a little understanding of types), is 
when you edit files with strict types active. But still, if that's too much of 
pain for a beginner, he's free to disable them.

Types are designed in a way enhancing the languages experience while avoiding 
nearly every impact for people who want to ignore them.

And that's great.

And that's why we shall continue on improving our *optional* type system.

Thanks,
Bob
--
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

[Fleshgrinder]

On 4/13/2016 10: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? :)
> 

Hahaha funny how many people consider Ceylon to be too academic. :)

I personally just want to make the language more consistent, secure (in
terms of introduction of bugs and error handling), and better suited for
real enterprise and high performance usage. And of course learn a
shitload about language design along the way. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Stanislav Malyshev]

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? :)
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Final properties

[Stanislav Malyshev]

Hi!

> Well, no. The differences are well explained in the deprecation RFC:
> 
> https://wiki.php.net/rfc/var_deprecation

"var is currently a simple alias for public. "

> The documentation states the *var* is a substitute for *public* but in
> reality it isn't. 

How exactly it isn't? Except for "static"/"const" thing (which is really
a parser glitch and could be easily fixed if anybody cared) I don't see
a difference. Pretending like that static/const thing is a serious issue
that warrants some deep changes makes no sense to me - it's just a very
minor bug.

> It is different to a constant in many ways:
> 
> - It is bound to the instance and GCed with it.

Don't see why is it good or why should I care.For all I care it may
never be GCed at all (such as interned strings), and userland developer
should not be worrying about these details anyway.

> - It can be set in the constructor.
> - It can be cloned in __clone.

I find the idea that you have special methods that have magic about
variables not available to other methods rather unwise. And, you forgot
__wakeup for example, unless you're not going to ever serialize your
value object. And maybe other use cases. The point is, you are building
very complex mechanism here that is too magic, and it is going to break
in weird ways because it doesn't work like the rest of language works.

It also promotes bad design, as unless you want to track stack traces,
you'd be able to touch these vars only in magic methods, thus requiring
placing the code dealing with these vars in each of those methods and
only there - you can't put this code in a different method, for example,
because that method won't be magic. So, no refactoring for magic methods.

> public function update(): void {
> $this->changed = new DateTimeImmutable;
> }

I don't see how $created works better than $changed. Moreover, it looks
rather strange that you have getter for $changed but not for $created.
To achieve consistency and avoid confusing people, you probably would
also have getCreated() anyway - which then makes "val" completely redundant.

> To avoid that child classes change the signature of a property from a
> parent class if that is not desired. This is especially useful if you
> intend to use public properties as part of your API or simply want to

I think that's not how it is done by all code I've seen so far - they
use getters instead. Now, we can say we want to get rid of getters, but
then I still don't see what use case final serves. I mean, "final is to
make things unchangeable" is not a use case - it just restating the same
thing in different words. The real question is *why* you need to make
them unchangeable?

> I am not saying that public properties should be part of an API. As I
> wrote already and as Larry Garfield pointed out, having them as part of
> the public API would mean that interfaces should be able to declare them
> and that classes should be able to implement hooks. In other words:

Exactly. So, unless we implement tons of other things, you can't really
use it, and even then it's unclear why you want to use it.

> For the reasons mentioned at the top and in the thread where we
> discussed the deprecation. :)

Well, I see no real reason there and deprecation failed, as it should
have. I don't exactly buy the argument of "we tried to deprecate var,
unsuccessfully, therefore there is a problem with it", and the only real
issue I have seen, as I mentioned above, is that minor static/const
glitch.

> I hope I was able to explain the *var*, *val*, and *final* idea and I
> encourage you to check out Java, Scala, Ceylon, ...

I know about existence of Java, Scala, etc. but "look at Java" is not a
very good explanation - Java is big, so it would be useful to clarify
what exactly I am supposed to be looking at and how it should convince
me with regard to PHP.
Also, I remind that both Java and Scala are compiled fully statically
strict typed languages, and PHP is not.

> would add a lot of benefit but other benefits. The main advantage would
> be that the objects could be considered safe at runtime for concurrency

Which is completely useless for PHP as it does not have
shared-environment concurrency and most likely never will. Also,
experience shows immutable value objects, while nice, does not solve
much of concurrency problems. Data structures are the real problem, and
immutable data structures are way harder to do. Anyway, this is
irrelevant for PHP in any case.

> (not a feature we currently have in PHP but still holds true) and would
> not require one to take care of copy on write all the time.

Err, how? The objects may be immutable but that says nothing of the
values within. So you'd still have to track them.
You could theoretically make some performance gains, maybe, by caching
property lookups, etc. for immutable objects, but I don't think you'd
gain too much compared to what we have now.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP 

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

[Stephen Coakley]

On Wed, 13 Apr 2016 10:53:13 -0600, Levi Morrison wrote:

> Continued (hit send by hotkey accident):
> 
> On Wed, Apr 13, 2016 at 10:50 AM, Levi Morrison  wrote:
>> First, some background: several versions of PHP ago authors of
>> functions and methods could only restrict types to the array type or a
>> class/interface type. We slowly added some other types such as callable
>> and primitive types. These tools have been invaluable to those who care
>> about restricting the types of their inputs and outputs. This type
>> information reduces the code each author has to write if they want to
>> restrict to working with certain types and it also provides a form of
>> documentation. Overall these features have been well received and are
>> considered a good thing to do.
>>
>> However, as we have added these new restrictions we still cannot
>> express exactly what types are permitted in some common cases.
>>
>>   1. Return types cannot specify the function will return only type T
>>   or Null.
>>   2. Parameter types cannot express that an iterable type is required.
>> It's common for functions to work a stream of data and it is irrelevant
>> if it is an array or a Traversable object.
>>   3. Parameter types cannot express that that the parameter must
>> implement two different interfaces. For example, requiring a parameter
>> to implement both Countable and Traversable cannot be done.
>>
>> There are some common work-arounds to these issues:
>>
>>   - Omit the type information and rely on documentation.
>>   - Check the parameter type inside the function (eg
>> `assert(is_array($x) || $x instanceof Traversable)`)
>>   - Introduce a new type that embodies the restrictions. If this in an
>> interface it must be implemented by every object you hope to use the
>> restriction with.
>>
>> In some cases these work-arounds are tolerable. However, some of them
>> are really painful.
>>
>>   - Requiring a new supertype is intrusive. Code cannot always be
>> changed to use the new supertype. For example:
>> - Upstream projects that would not benefit from your changes.
>> - Primitives cannot be extended except by altering the engine.
>> In these cases a new type has to be introduced that proxies
>> behavior to the underlying object/primitive.
>>   - Relying on documentation can lead to subtle and hard to diagnose
>> issues when it is used incorrectly. Erroring immediately is sometimes
>> preferable.
>>
>> All of these issues I've outlined can be nicely resolved by adding two
>> new kinds of types to our system: union and intersection types. A union
>> type requires the variable to match at least one of the types. An
>> intersection type requires the variable to match all of the types. The
>> vertical par symbol (OR) is used for unions and ampersand (AND) is used
>> for intersections. For example:
>>
>> function (A | B $var); would require $var to be either type A or
>> type B.
>> function (A & B $var); would require $var to be type A and type B.
>>
>> To accommodate the common use-case of returning some type or Null we
>> would need to formally allow `Null` as an explicit type:
>>
>> function (): T | Null;
>>
>> Since this is a common use case some languages have a short-hand
>> notation to represent a union with Null:
> 
> function (): ?T;
> 
> Examples of such languages include Swift, C#, OCaml and Hack (though the
> symbol is sometimes in the front and sometimes in the back.
> 
> Later today I will be submitting RFCs for each of these proposals.
> Although they can work independently it is helpful to understand the
> overall goal and how they fit together, which has been the purpose of
> this email. Feedback for each RFC will belong in the thread for that
> piece, but discussion about the ideas overall is better suited here.

COOLNESS!! +10

I really like this mindset of a general solution to these stricter types. 
I think it will present a more consistent "interface" for using types 
across PHP in the future.

In general, this is a more general and elegant solution to nullable type 
in properties, hints, and return types.

I am eager to see what you have in those RFCs. 

-- 
Stephen

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

[Fleshgrinder]

On 4/13/2016 9:57 PM, Levi Morrison wrote:
> On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder  wrote:
>> Nothing to add other than +1, however, didn't you already write those?
>>
>> https://wiki.php.net/rfc/nullable_types
>> https://wiki.php.net/rfc/union_types
>>
>> Or is this just an announcement that these will be finalized now?
>>
>> Btw. I am in favor of having the question mark as a suffix and not as a
>> prefix because it is more readable and more natural to type.
>>
>> function fn(string? $str): bool?;
>>
>> Declare a function with the name fn that takes a string argument that is
>> nullable which will return a bool or null.
>>
>> That is exactly how I would think about the above while writing and
>> reading. :)
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
> 
> I have written them but later they will be formally moved to Under
> Discussion and will create new threads for them here on the mailing
> list.
> 

Awesome, let me know if I can be of any help, even if it is only proof
reading. This is an extremely valuable addition that I want to have.

May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this topic:

http://ceylon-lang.org/documentation/tour/types/

Ceylon is very nicely designed regarding union and intersection types
and I think it can add value to learn from these people too. I am not
handing out this because I think that you don't know what you are doing.
The opposite is the case. However, Ceylon is very young and I don't
think many people know of it; while you probably already know all the
oldies who support union and intersection types. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Levi Morrison]

On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder  wrote:
> Nothing to add other than +1, however, didn't you already write those?
>
> https://wiki.php.net/rfc/nullable_types
> https://wiki.php.net/rfc/union_types
>
> Or is this just an announcement that these will be finalized now?
>
> Btw. I am in favor of having the question mark as a suffix and not as a
> prefix because it is more readable and more natural to type.
>
> function fn(string? $str): bool?;
>
> Declare a function with the name fn that takes a string argument that is
> nullable which will return a bool or null.
>
> That is exactly how I would think about the above while writing and
> reading. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>

I have written them but later they will be formally moved to Under
Discussion and will create new threads for them here on the mailing
list.

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

Re: [PHP-DEV] Final properties

[Fleshgrinder]

On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
> Hi!
> 
>> The *var* keyword is not going to be deprecated and its meaning is 
>> currently kind of ambiguous. I tried to assign it a new meaning in
>> the
> 
> Why is it ambiguous? It's pretty well defined, it's the same as public.
> 

Well, no. The differences are well explained in the deprecation RFC:

https://wiki.php.net/rfc/var_deprecation

The documentation states the *var* is a substitute for *public* but in
reality it isn't. Also the name is ambiguous because /var/ does not mean
/public/. ;)

On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
>> class Foo {
>>
>> val $x;
>>
>> var $y;
>>
>> val $z;
>>
>> }
>>
>> class Bar extends Foo {
>>
>> var $x;
>>
>> $y;
>>
>> $z;
>>
>> }
> 
> This looks very unobvious what is supposed to be going on here. I'd
> much prefer to have every specification be explicit.
> 

This was less a proposal regarding how it will be in userland and more
about how the inheritance should be. I fully and completely agree with
you that the full definition should be restated if a property is going
to be redeclared in a child in userland. Either 1:1 or by changing what
is allowed to change. The above example in userland with a more
realistic example would be:

class Foo {

public float val $x;

public float val $y;

}

class Bar extends Foo {

public float var $x;

public float var $y;

}

On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
>> The /z/ will stay a *val* (immutable) because its parent
>> declaration is defined as such.
>>
>> class Point {
>>
>> final public float val $x = 0.0;
> 
> Wait, how is this different from a constant?
> 

It is different to a constant in many ways:

- It is bound to the instance and GCed with it.
- It can be set in the constructor.
- It can be cloned in __clone.

Of course there are other added benefits of properties like the ability
to contain object instances while not being reassignable but internally
mutable. Again, the example was more about how things should work and
not meant to be useful in any context. Here is a better example,
however, some compromises with non-final class and property visibility
to illustrate features:

class Entity {

final public int val $id;

final public DateTimeImmutable val $created;

final protected DateTimeImmutable var $changed;

final protected OtherEntity var $other_entity;

public function __construct(
int $id,
DateTimeImmutable $created,
DateTimeImmutable $changed,
OtherEntity $other_entity
) {
assert(
'$created <= $changed',
'`created` cannot be less than `changed`'
);
$this->id = $id;
$this->created = $created;
$this->changed = $changed;
$this->other_entity = $other_entity;
}

public function __clone() {
$this->other_entity = clone $this->other_entity;
}

public function getChanged(): DateTimeImmutable {
return $this->changed;
}

public function update(): void {
$this->changed = new DateTimeImmutable;
}

On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
>> The *final* keyword could be added via another RFC and it would
>> have the same meaning as the *final* keyword for classes and
>> methods: freeze the definition. This is why the *MutablePoint*
>> results in fatal errors: it tries to redeclare /x/ and /y/ from
>> *val* to *var* although they are *final*.
> 
> I'm not sure I understand what is the point in freezing the
> definition. Could you explain use case for such thing?
> 

To avoid that child classes change the signature of a property from a
parent class if that is not desired. This is especially useful if you
intend to use public properties as part of your API or simply want to
update an existing anemic domain model by slowly adding the newly
proposed features here and to find bugs (e.g. assignments of wrong data
types, assignments at all, ...).

I am not saying that public properties should be part of an API. As I
wrote already and as Larry Garfield pointed out, having them as part of
the public API would mean that interfaces should be able to declare them
and that classes should be able to implement hooks. In other words:

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

@Larry: I know that I wrote that I don't get why you brought up that RFC
but now I know (and why I wrote a short addendum mail). ;)

On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
>> I think that Scala's *val*/*var* approach could really help us to
>> make *var* usable again in a meaningful manner and it corresponds
>> nicely to the concept of /value objects/ and related concepts with
>> its naming scheme.
> 
> I'm not sure why var is unusable and why it is a worthy goal to make
> it "usable again" - i.e. what exactly we are trying to 

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

[Stanislav Malyshev]

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?

> 
>  class Foo () {
>   int $a = 0;
> }
> $a = new Foo();
> $b = $a->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?

-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Wiki

[Adler Luiz Pereira Freitas]

Hello,
I would like to help in php documentation translation, my username is
*adlerluiz*
-- 
Adler Luiz

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

[Fleshgrinder]

Nothing to add other than +1, however, didn't you already write those?

https://wiki.php.net/rfc/nullable_types
https://wiki.php.net/rfc/union_types

Or is this just an announcement that these will be finalized now?

Btw. I am in favor of having the question mark as a suffix and not as a
prefix because it is more readable and more natural to type.

function fn(string? $str): bool?;

Declare a function with the name fn that takes a string argument that is
nullable which will return a bool or null.

That is exactly how I would think about the above while writing and
reading. :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] IntlCharsetDetector

[Fleshgrinder]

On 4/12/2016 1:25 AM, Sara Golemon wrote:
> On Mon, Apr 11, 2016 at 4:09 PM, Stanislav Malyshev  
> wrote:
>> The API looks a bit strange - new IntlCharsetDetector($text) and then
>> detect(). Can't we just have detect([$text])?
>>
> I went with a direct wrapping of the underlying API because it always
> feels like we regret adding magic eventually.  It's trivial for some
> composer installable library to wrap this into something nicer.  In
> fact, one probably WOULD use a userspace library in order to provide
> fallback to mb_detect_encoding() on PHP < 7.1
> 
> That said, how do you feel about compromising by adding this function
> in addition to the raw API?
> 
> function ucsdet_detect_encoding(string $text, string $hint = null,
> bool $filter = false) {
>   $det = new IntlCharsetDetector($text);
>   if ($hint !== null) {
> $det->setDeclaredEncoding($hint);
>   }
>   $det->enableInputFiltering($filter);
>   return $det->detect()['name'];
> }
> 
> That'll give simplicity for the 80% case (I have a string, I want a
> best guess) but still provide the true API for consideration of
> confidence and/or other guesses.
> 
> -Sara
> 

I agree with Stanislav here. I think that the HHVM implementation is
much better because it enables dependency injection and does not fall
back to arbitrary native arrays. However, the detect method should take
an optional text argument directly, as Stanislav proposed. I understand
the argument that extending native interfaces sometimes led to problems
but simply copying stuff without thinking of better ways is also not
really solving all problems.

In our native language:

class IntlCharsetDetector {

fn __construct(string $text = null);

fn setText(string $text): void;

fn setDeclaredEncoding(string $encoding): void;

// I incorporated your proposal here because I think it is
// extremely useful.
fn detect(
string $text = null,
string $hint = null,
bool $filter = false
): IntlEncodingMatch;

fn detectAll(string $text = null): array;

fn inputFilterEnabled(): bool;

fn enableInputFilter(): void;

fn disableInputFilter(): void;

fn getDetectableCharsets(): array;

fn enableDetectableCharset(string $charset): void;

fn disableDetectableCharset(string $charset): void;

static fn getAllDetectableCharsets(): array;

}

NOTE how I changed the methods that take bool arguments int he Java
implementation to direct calls. This removes the necessity to validate
the arguments of the caller and results in a very clean API that does
not require extensive documentation to be easily comprehensible.

class IntlEncodingMatch {

fn isValid(): bool;

fn getEncoding(): string;

fn getConfidence(): int;

fn getLanguage(): string;

fn getUtf8(): string;

}

NOTE that I also use *getUtf8* as does HHVM and not simply *getString*
as it is used in the Java implementation because again it reduces the
amount of documentation reading because it is clear what this method is
supposed to do (return). I did not write *getUTF8* though because I
think it violates the /camelCase/ rule but that is not really clarified
in the PHP Coding Standards and thus hard to argue about.

Having the *IntlEncodingMatch* object as a result has the advantage that
one does not need to look up the documentation every time they want to
handle the result, no creation of the strings to access the offsets at
runtime, no error prone mistyping issues plus the added value of type
hinting against it.

That being said, the procedural functions could still return native
arrays. I do not see a reason why the procedural versions have to be 1:1
mapping to the OO versions.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Dmitry Stogov]

We are talking only about unsettling of typed properties



From: guilhermebla...@gmail.com 
Sent: Wednesday, April 13, 2016 16:08
To: Dmitry Stogov
Cc: Nikita Popov; Stanislav Malyshev; internals; Joe Watkins; Zeev Suraski
Subject: Re: [PHP-DEV] Re: Typed properties patch


Hi,

Unsetting properties is used by a range of libraries I am aware of, including 
Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter would 
not only address the unsetting hack, but also allow read only properties (final 
properties). IMHO, we should look back at that implementation (it was mainly 
rejected because of the patch complexity (not the idea), which would kill two 
birds with one stone.

Cheers,

On Apr 13, 2016 2:59 AM, "Dmitry Stogov" 
> wrote:


On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:
Hi!

 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.
I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.

 > 3) disable unset
This sounds very weird. Why I would suddenly unable to unset a property?

Because if you unset() a property it's type is not guaranteed anymore.

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 
*/
?>

As we can't be sure where the property may be unset(), we won't be able to use 
optimized code at all (even in first place).

Thanks. Dmitry.





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

Re: [PHP-DEV] [RFC] [Discussion] Octal overflow detection

[Fleshgrinder]

On 4/13/2016 4:38 AM, Sara Golemon wrote:
> https://wiki.php.net/rfc/octal.overload-checking
> Because having this expression evaluate to true makes me sad: ("\000"
> === "\400")
> 
> -Sara
> 

+1 from my side right away. We all settled with the fact that "==" is
completely useless but at least "===" should be:

reflexive
symmetric
transitive
consistent

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Levi Morrison]

Continued (hit send by hotkey accident):

On Wed, Apr 13, 2016 at 10:50 AM, Levi Morrison  wrote:
> First, some background: several versions of PHP ago authors of
> functions and methods could only restrict types to the array type or a
> class/interface type. We slowly added some other types such as
> callable and primitive types. These tools have been invaluable to
> those who care about restricting the types of their inputs and
> outputs. This type information reduces the code each author has to
> write if they want to restrict to working with certain types and it
> also provides a form of documentation. Overall these features have
> been well received and are considered a good thing to do.
>
> However, as we have added these new restrictions we still cannot
> express exactly what types are permitted in some common cases.
>
>   1. Return types cannot specify the function will return only type T or Null.
>   2. Parameter types cannot express that an iterable type is required.
> It's common for functions to work a stream of data and it is
> irrelevant if it is an array or a Traversable object.
>   3. Parameter types cannot express that that the parameter must
> implement two different interfaces. For example, requiring a parameter
> to implement both Countable and Traversable cannot be done.
>
> There are some common work-arounds to these issues:
>
>   - Omit the type information and rely on documentation.
>   - Check the parameter type inside the function (eg
> `assert(is_array($x) || $x instanceof Traversable)`)
>   - Introduce a new type that embodies the restrictions. If this in an
> interface it must be implemented by every object you hope to use the
> restriction with.
>
> In some cases these work-arounds are tolerable. However, some of them
> are really painful.
>
>   - Requiring a new supertype is intrusive. Code cannot always be
> changed to use the new supertype. For example:
> - Upstream projects that would not benefit from your changes.
> - Primitives cannot be extended except by altering the engine.
> In these cases a new type has to be introduced that proxies
> behavior to the underlying object/primitive.
>   - Relying on documentation can lead to subtle and hard to diagnose
> issues when it is used incorrectly. Erroring immediately is sometimes
> preferable.
>
> All of these issues I've outlined can be nicely resolved by adding two
> new kinds of types to our system: union and intersection types. A
> union type requires the variable to match at least one of the types.
> An intersection type requires the variable to match all of the types.
> The vertical par symbol (OR) is used for unions and ampersand (AND) is
> used for intersections. For example:
>
> function (A | B $var); would require $var to be either type A or type B.
> function (A & B $var); would require $var to be type A and type B.
>
> To accommodate the common use-case of returning some type or Null we
> would need to formally allow `Null` as an explicit type:
>
> function (): T | Null;
>
> Since this is a common use case some languages have a short-hand
> notation to represent a union with Null:

function (): ?T;

Examples of such languages include Swift, C#, OCaml and Hack (though
the symbol is sometimes in the front and sometimes in the back.

Later today I will be submitting RFCs for each of these proposals.
Although they can work independently it is helpful to understand the
overall goal and how they fit together, which has been the purpose of
this email. Feedback for each RFC will belong in the thread for that
piece, but discussion about the ideas overall is better suited here.

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

[PHP-DEV] Improving PHP's type system

[Levi Morrison]

First, some background: several versions of PHP ago authors of
functions and methods could only restrict types to the array type or a
class/interface type. We slowly added some other types such as
callable and primitive types. These tools have been invaluable to
those who care about restricting the types of their inputs and
outputs. This type information reduces the code each author has to
write if they want to restrict to working with certain types and it
also provides a form of documentation. Overall these features have
been well received and are considered a good thing to do.

However, as we have added these new restrictions we still cannot
express exactly what types are permitted in some common cases.

  1. Return types cannot specify the function will return only type T or Null.
  2. Parameter types cannot express that an iterable type is required.
It's common for functions to work a stream of data and it is
irrelevant if it is an array or a Traversable object.
  3. Parameter types cannot express that that the parameter must
implement two different interfaces. For example, requiring a parameter
to implement both Countable and Traversable cannot be done.

There are some common work-arounds to these issues:

  - Omit the type information and rely on documentation.
  - Check the parameter type inside the function (eg
`assert(is_array($x) || $x instanceof Traversable)`)
  - Introduce a new type that embodies the restrictions. If this in an
interface it must be implemented by every object you hope to use the
restriction with.

In some cases these work-arounds are tolerable. However, some of them
are really painful.

  - Requiring a new supertype is intrusive. Code cannot always be
changed to use the new supertype. For example:
- Upstream projects that would not benefit from your changes.
- Primitives cannot be extended except by altering the engine.
In these cases a new type has to be introduced that proxies
behavior to the underlying object/primitive.
  - Relying on documentation can lead to subtle and hard to diagnose
issues when it is used incorrectly. Erroring immediately is sometimes
preferable.

All of these issues I've outlined can be nicely resolved by adding two
new kinds of types to our system: union and intersection types. A
union type requires the variable to match at least one of the types.
An intersection type requires the variable to match all of the types.
The vertical par symbol (OR) is used for unions and ampersand (AND) is
used for intersections. For example:

function (A | B $var); would require $var to be either type A or type B.
function (A & B $var); would require $var to be type A and type B.

To accommodate the common use-case of returning some type or Null we
would need to formally allow `Null` as an explicit type:

function (): T | Null;

Since this is a common use case some languages have a short-hand
notation to represent a union with Null:

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

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

[Larry Garfield]

On 4/13/16 10:55 AM, Lin Yo-An wrote:

Hi internals,


The javascript engine V8 uses a strategy called "startup snapshot" to
optimize app load time (see
http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
details)

The approach used by V8 creates a snapshot from heap, so the V8Context
could be reused directly without re-running the bootstraping code.

I think running javascript app in the browser is somehow like we run php
script for each requests where the app bootstrapping code is required to be
executed repeatedly for each request.

Currently, our opcache extension can cache the byte codes, but the byte
codes still need to be executed every time when bootstrapping an app, and
which increases the overhead for each request.

For example, a lot of applications use composer to initialize the class
loader via the statement below:

 require "vendor/autoload.php";

The statement above produces thousands of byte code to run, which is to
make an app ready. (If you use vld extension to show the opcodes)

However, if we can support a simple syntax to describe what is doing
"bootstrap", we are able to create a startup snapshot from it.


The proposal here want to introduce some new syntax to optimize app load
time though the below syntax:

 bootstrap "vendor/autoload.php";  // caches the context after running
this script.

Or

 bootstrap {
require "vendor/autoload.php";
// do something else for making app ready
 };

And of course, we might detect the bootstrap script automatically without
creating new syntax and opcodes, but I think it's hard to do because PHP
applications can be written by many ways...


Questions


I don't know if this approach is doable or not. Or maybe we can support
this in a separated extension instead of changing the zend core?

Do you guys think it's doable? would you like to share your idea for this?


I have no idea how feasible it is for the engine.  It may be impossible, 
or it may be straightforward.  However, if it can be done then it would 
allow for vastly improved architecture for large applications.  Many 
large systems (Drupal being the example I know best) spend a lot of time 
trying to optimize their bootstrap, loading as few services as possible, 
adding complexity and indirection to lazy-load services, etc. because 
that code is executed on every request.  That means even a single 
function call removed along that critical path can add up to a lot of 
time over the course of a day.  If instead we could snapshot a point in 
time and restart there, we could remove all of that optimization and 
make the bootstrap process actively load most of the system, then freeze 
it; then requests come in to a fully booted system and we save a ton of 
time initializing services on every request.  I'd love that.


The trick, of course, is that PHP's standard setup model assumes that 
the environment is created before the code is even loaded.  The 
superglobals, for instance, exist before the first line of userspace 
code, yet those are the things that will vary per run *after* the 
snapshot is made.  And then there's the question of how to detect and 
trigger a re-bootstrap, say when code is updated.  For that reason, I 
suspect such a change would require far more than just a few new 
keywords; there would need to be some sever-level specification of a 
bootstrap script that is distinct from the user-facing script that the 
web server executes, and a few thousand edge cases to think about.


--
--Larry Garfield


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

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

[Marco Pivetta]

While this seems interesting, how would it address storing any context
information of extension?

The code above (in your examples) only stores information about the
autoload stack, but anything that would rely on any extension (core or pecl
or custom) would have to serialize information that is possibly not even
available in userland.

Any clue on that? Would it be acceptable to have it just fail/fatal?


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 13 April 2016 at 17:55, Lin Yo-An  wrote:

> Hi internals,
>
>
> The javascript engine V8 uses a strategy called "startup snapshot" to
> optimize app load time (see
> http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for
> more
> details)
>
> The approach used by V8 creates a snapshot from heap, so the V8Context
> could be reused directly without re-running the bootstraping code.
>
> I think running javascript app in the browser is somehow like we run php
> script for each requests where the app bootstrapping code is required to be
> executed repeatedly for each request.
>
> Currently, our opcache extension can cache the byte codes, but the byte
> codes still need to be executed every time when bootstrapping an app, and
> which increases the overhead for each request.
>
> For example, a lot of applications use composer to initialize the class
> loader via the statement below:
>
> require "vendor/autoload.php";
>
> The statement above produces thousands of byte code to run, which is to
> make an app ready. (If you use vld extension to show the opcodes)
>
> However, if we can support a simple syntax to describe what is doing
> "bootstrap", we are able to create a startup snapshot from it.
>
>
> The proposal here want to introduce some new syntax to optimize app load
> time though the below syntax:
>
> bootstrap "vendor/autoload.php";  // caches the context after running
> this script.
>
> Or
>
> bootstrap {
>require "vendor/autoload.php";
>// do something else for making app ready
> };
>
> And of course, we might detect the bootstrap script automatically without
> creating new syntax and opcodes, but I think it's hard to do because PHP
> applications can be written by many ways...
>
>
> Questions
> 
>
> I don't know if this approach is doable or not. Or maybe we can support
> this in a separated extension instead of changing the zend core?
>
> Do you guys think it's doable? would you like to share your idea for this?
>
>
>
>
>
>
> Best Regards,
>
> Yo-An Lin
>

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

[Lin Yo-An]

Hi internals,


The javascript engine V8 uses a strategy called "startup snapshot" to
optimize app load time (see
http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
details)

The approach used by V8 creates a snapshot from heap, so the V8Context
could be reused directly without re-running the bootstraping code.

I think running javascript app in the browser is somehow like we run php
script for each requests where the app bootstrapping code is required to be
executed repeatedly for each request.

Currently, our opcache extension can cache the byte codes, but the byte
codes still need to be executed every time when bootstrapping an app, and
which increases the overhead for each request.

For example, a lot of applications use composer to initialize the class
loader via the statement below:

require "vendor/autoload.php";

The statement above produces thousands of byte code to run, which is to
make an app ready. (If you use vld extension to show the opcodes)

However, if we can support a simple syntax to describe what is doing
"bootstrap", we are able to create a startup snapshot from it.


The proposal here want to introduce some new syntax to optimize app load
time though the below syntax:

bootstrap "vendor/autoload.php";  // caches the context after running
this script.

Or

bootstrap {
   require "vendor/autoload.php";
   // do something else for making app ready
};

And of course, we might detect the bootstrap script automatically without
creating new syntax and opcodes, but I think it's hard to do because PHP
applications can be written by many ways...


Questions


I don't know if this approach is doable or not. Or maybe we can support
this in a separated extension instead of changing the zend core?

Do you guys think it's doable? would you like to share your idea for this?






Best Regards,

Yo-An Lin

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

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-13 06:35:32+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.23% -0.42%  0.62%  
  7.23%
:-|   Drupal 7.36 cgi -T1  0.17%  0.60% -0.07%  
  4.22%
:-|   MediaWiki 1.23.9 cgi -T5000  0.00%  0.09%  1.62%  
  2.98%
:-|   bench.php cgi -T100  0.00%  0.01% 23.77%  
  1.95%
:-|  micro_bench.php cgi -T10  0.01%  0.02%  5.88%  
  3.65%
:-|  mandelbrot.php cgi -T100  0.06%  0.22% 28.92%  
  9.56%
---
* 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-13/

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

[guilhermebla...@gmail.com]

Hi,

Unsetting properties is used by a range of libraries I am aware of,
including Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter
would not only address the unsetting hack, but also allow read only
properties (final properties). IMHO, we should look back at that
implementation (it was mainly rejected because of the patch complexity (not
the idea), which would kill two birds with one stone.

Cheers,
On Apr 13, 2016 2:59 AM, "Dmitry Stogov"  wrote:



On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

> Hi!
>
>  Thanks for your time reviewing the patch, appreciated.
>>
>>  > 1) nullable properties
>>
>>  I agree that we need a way to that, but I would rather see it
>> covered by nullable types rfc.
>>
> I think this is an attempt to achieve more type safety than even fully
> typed languages like Java, and it will only get in the way in PHP.
>
>  > 3) disable unset
>>
> This sounds very weird. Why I would suddenly unable to unset a property?
>

Because if you unset() a property it's type is not guaranteed anymore.

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 */
?>

As we can't be sure where the property may be unset(), we won't be able to
use optimized code at all (even in first place).

Thanks. Dmitry.



>

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

Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing

[Yasuo Ohgaki]

Hi Stas,

On Wed, Apr 13, 2016 at 12:50 PM, Stanislav Malyshev
 wrote:
>> Yes and no.
>> Patch uses php_random_bytes(), so it uses appropriate PRNG for the system.
>> php_random_bytes() is supposed to be available always.
>
> True, but is it always OK to export its state to anybody who asks, on
> demand, in unlimited numbers? I'm not so sure.
>
>> Experts say secure PRNG like /dev/urandom is safe.
>
> What's "like /dev/urandom"? Each PRNG can have different properties.

Yes, but all RPNG in major OSes are supposed to be secure PRNG.

>
>> Why shouldn't?
>> It's just a use case in the wild.
>
> If you want to test use case, test on real application, not on
> microbenchmark. And by real application I mean one currently used, of
> which none regenerate session IDs on every request, and none have
> reasons to. Optimizing for narrow use case which doesn't even exist yet
> against thousands of apps that already do makes no sense to me.
>
>> If time stamp based session management is used, there is no worries
>> updating session ID on every request.
>
> Of course there are worries, it would generate huge traffic to session
> storage which is completely unnecessary. Moreover, many application
> would be broken under such model. Of course, you are free to build your
> own app using such model, but it's in no way a best practice and it does
> not deserve to be target of global optimization of session module for it.

Users updating session ID always do not concern disabling lazy_write,
I suppose.

>> Discussion is based on FUD.
>> AFAIK, I saw papers state PRNGs are secure enough, but opposite.
>> (We can safely ignore side channel attack issue, I suppose)
>
> We can't claim both PRNG are secure and PRNG aren't secure. So which is it?

When we discussed about randam_*() functions, links to pages are
posted.

>
> In any case, I don't see how this mandates turning on strict sessions. I
> know you want it to be the default, but it doesn't seem to be related to
> this topic.

Probability of collision is close to zero, but it's not zero unless it
is validated. It's a precaution for broken PRNG on new OSes, too.

It's closely related to me, different point of view.

>
>> There is no BC.
>> Removed INI are just ignored if users are used.
>
> But users used them for something. If that something doesn't happen,
> then it's broken.

INI setting is always worked this way. I don't see problem ignoring settings
e.g. register_globals=on, magic_quote_gpc=on

>
>> Question is "Current session ID is generation is optimal way?" or "Is it
>> better than proposed one?" If so, why?
>
> Yes, it's better - it does not export PRNG state needlessly, and it's
> already proven to work by thousands of applications. I'm OK with adding
> a non-hashed option, for people that want to try it out, and eventually
> if everybody ends up using it and nothing bad happens, we could phase
> out the hashed ones then. But just dropping them out of the blue and
> making non-hashed the only option does not look like a good solution.
>
>> Crypto experts say "secure PRNG is safe", why should we care too much
>> about secure PRNG vulnerability? Why we should invent our own entropy
>> added random value and take hash of it?
>
> We should not invent our own PRNG. Hashing it though seems like a
> reasonable precaution.

If we have to hide PRNG state, skipping random bytes would do
the job. This is much simpler and faster.

We cannot say current implementation is better. SSL/TLS
removed multiple use of hashes because it could be weaker.
Use of additional hashing does not necessary a good thing as
distribution of hashed value (session ID) is biased by hash algorithm.
Only 32 bytes are read from PRNG by default. Therefore, it's close
to direct exposure even with hash.

We probably should discuss php_random_bytes() if it is considered as
crypto secure or not. If yes, we may simply rely on it. (My discussion
is based on this) If not, we need to improve php_random_bytes() implementation.

Regards,

P.S.
Another reason why I would like to remove hashing is availability
of stronger hashes. Hash extension can be disabled, thus there
should be fallback code. It's not clean. Stronger hashes are slower
also.


--
Yasuo Ohgaki
yohg...@ohgaki.net

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

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

[Dmitry Stogov]

On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

Hi!


 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.

I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.


 > 3) disable unset

This sounds very weird. Why I would suddenly unable to unset a property?


Because if you unset() a property it's type is not guaranteed anymore.

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

?>

As we can't be sure where the property may be unset(), we won't be able 
to use optimized code at all (even in first place).


Thanks. Dmitry.






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