Re: [PHP-DEV] Object Type Casting Reloaded

[Marcos Passos]

Such a feature would be very helpful to ensure type safety! A big +1!

On Mon, Apr 22, 2019 at 19:51 Benjamin Morel 
wrote:

> Hi Azjezz, thanks for jumping in!
>
> > I have been using HackLang for quite a while now and i believe they have
> a better solution for this, and it would awesome to see it in PHP, the `as`
> operator.
>
> If I understand correctly, `as` is an operator that performs type checks
> but never casts like () does.
> This looks like a serious candidate for an alternative syntax to the one I
> proposed!
>
> - Ben
>

Re: [PHP-DEV] Mixed type-hint

[Marcos Passos]

It is just a (draft) proposal. Anyway, the RFC does not force you to
declare a mixed type but brings an option for who wants to.

On Fri, Feb 8, 2019 at 13:03 Robert Korulczyk  wrote:

> There is no reason to introduce `mixed` type-hint if it does not provide
> any validation and works the same as no type-hint at all.
>
> Regards,
> Robert Korulczyk
>
> W dniu 08.02.2019 o 15:54, Marcos Passos pisze:
> > Those cases should be handled with runtime validation, there is no
> reason for changing the concept of mixed.
> >
> > On Fri, Feb 8, 2019 at 12:39 Robert Korulczyk  <mailto:rob...@korulczyk.pl>> wrote:
> >
> > > Could you clarify on a use-case for changing the semantics of
> `mixed`?
> >
> > For example storage which does not allow to store null. Like simple
> cache which treats null as "miss", so it is not able to cache null as value.
> >
> > Obviously it is not a deal breaker and use case is quite rare
> anyway, but this is just example when mixed type-hint may work as actual
> type-hint, not
> > just replacement for PHPDoc or equivalent of... nothing.
> >
> >
> >
> > Regards,
> > Robert Korulczyk
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

Re: [PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[Marcos Passos]

I believe we can adopt the behaviour of mature languages that supports this
feature. Java, for instance, throw a compile-time error saying that the
method signature is ambiguous.

On Sun, Feb 3, 2019 at 17:51 David Rodrigues  wrote:

> Em dom, 3 de fev de 2019 às 17:19, Rowan Collins 
> escreveu:
>
> > On 03/02/2019 19:00, Christoph M. Becker wrote:
> > > On 03.02.2019 at 19:39, David Rodrigues wrote:
> > >
> > >> overload function sum(int $a, int $b): int;
> > >> overload function sum(float $b, float $b): float;
> > > Which function would sum(17.4, 42) call?  Also consider:
> > >
> > >sum(PHP_INT_MAX, PHP_INT_MAX)
> > >
> > > vs.
> > >
> > >sum(PHP_INT_MAX+1, PHP_INT_MAX+1)
> >
> >
> > Yes, marking overloaded functions explicitly definitely helps, but I
> > think the dispatch part is more complex than it first seems. Classes and
> > interfaces require a bit of subtlety too:
> >
> > class Foo {}
> > class Bar extends Foo {}
> >
> > overload function foo(Foo $a, Foo $b);
> > overload function foo(Foo $a, Bar $b);
> > overload function foo(Bar $a, Foo $b);
> >
> > foo(new Bar, new Bar);
> >
>
> This example could be complex. So, what other languages does in cases like
> that? Java, for instance.
>
>
> >
> > There are plenty of cases more complex than this, e.g. when a class
> > implements multiple interfaces, and you need to find a matching
> signature.
> >
> > That's not to say it's impossible, just don't underestimate the edge
> > cases you'll need to legislate for.
> >
> > Oh, and note that return types can't participate in overloading, because
> > there's no concept of "desired type" to choose between them.
> >
>
> You are right, in general. But still is possible identify the desired type
> if return is used as argument to a typed parameter, but I still thinks that
> it could not be done in general terms, so maybe we should not includes
> return type to overloading.
>
>
> >
> > Regards,
> >
> > --
> > Rowan Collins
> > [IMSoP]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> David Rodrigues
>

Re: [PHP-DEV] [RFC] JIT

[Marcos Passos]

JIT, FFI, covariant return types and typed properties: what a year for PHP.

Thank you all for working on making PHP better and better.

- Marcos

Em qui, 31 de jan de 2019 às 08:54, Dmitry Stogov 
escreveu:

>
>
> On 1/31/19 1:15 PM, Albert Casademont wrote:
> > Hi all,
> >
> > This is fantastic news thank you! I was going to ask if JIT would also
> > work when Opcache is enabled with "opcache.file_cache_only".
>
> Unfortunately, not yet, but we are planning to move opcache into PHP-8
> core and allow optimization and JIT without caching.
>
> > Our use
> > case is a ReactPHP app that right now only has Opcache basically for the
> > optimizations and we do not use the standard shared memory portion. We
> > believe JIT could improve quite a lot these kinds of "long-running"
> > processes that can serve multiple requests per-process. Thanks a lot!
>
> Better to try and provide feedback right now.
> You can get sources and build PHP from the link in RFC.
> https://github.com/zendtech/php-src/
>
> Thanks. Dmitry.
>
> >
> > Best,
> >
> >
> >
> > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  > > wrote:
> >
> > Hi Internals,
> >
> >
> > I'm glad to finally propose including JIT into PHP.
> >
> >
> > https://wiki.php.net/rfc/jit
> >
> >
> > In the current state it may be included both into PHP-8, where we
> > are going to continue active improvement, and into PHP-7.4, as an
> > experimental feature.
> >
> >
> > Thanks. Dmitry.
> >
>

Re: [PHP-DEV] Unserializes, inheritance and allows_classes

[Marcos Passos]

>
> How would you fix this example, then? Perhaps we should add more examples
> in the docs.
>

But it closes for extension preventing the serialization of instances not
whitelisted. It may work for @internal or package private classes, but not
for public classes.

Em qui, 17 de jan de 2019 às 23:03, Marco Pivetta 
escreveu:

>
>
> On Fri, Jan 18, 2019 at 2:00 AM Marcos Passos 
> wrote:
>
>> How would you fix this example, then? Perhaps we should add more examples
>> in the docs.
>>
>
> You'd include all expected child classes in the list of `allowed_classes`.
> As for the docs, feel free to go ahead and edit them directly :+1:
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] Unserializes, inheritance and allows_classes

[Marcos Passos]

How would you fix this example, then? Perhaps we should add more examples
in the docs.

Em qui, 17 de jan de 2019 às 22:53, Marco Pivetta 
escreveu:

> On Fri, Jan 18, 2019 at 1:50 AM Marcos Passos 
> wrote:
>
>> Hi Marco,
>>
>> Also: nothing denies an attacker from defining a subtype to your class,
>>> then passing a malicious instance to your application.
>>
>>
>> Fact, but it also reveals a fragility in the solution in the sense that
>> one has to opt between flexible design or security.
>>
>> Em qui, 17 de jan de 2019 às 22:24, Marco Pivetta 
>> escreveu:
>>
>>>
>>> On Fri, Jan 18, 2019 at 12:49 AM Marcos Passos <
>>> marcospassos@gmail.com> wrote:
>>>
>>>> Hi internals,
>>>>
>>>> Today I stumbled upon a limitation when implementing the unserialize
>>>> method
>>>> of a serializable class which depends on an abstraction also
>>>> serializable.
>>>> Currently, there is no way to unserialize an object specifying a parent
>>>> class in the allowed_classes option:
>>>>
>>>> class SerializableBase implements \Serializable {
>>>> > }
>>>> > class SerializableChild extends SerializableBase {
>>>> > }
>>>> > class Foo implements \Serializable {
>>>> >private $dependency;
>>>> > public function __construct(SerializableBase $dependency) {
>>>> > $this->dependency = $dependency;
>>>> > }
>>>> > public function serialize() : string {
>>>> >  return \serialize($this->dependency);
>>>> > }
>>>> >public function unserialize($data) : void {
>>>> > $this->dependency = \unserialize($data, ['allowed_classes' =>
>>>> > SerializableBase::class]);
>>>> >}
>>>> > }
>>>>
>>>>
>>>> Is this an intentional limitation?
>>>>
>>>>
>>> Seems expected to me: `allowed_classes` is a whitelist, not a complex
>>> filter/ruleset.
>>>
>>> Also: nothing denies an attacker from defining a subtype to your class,
>>> then passing a malicious instance to your application.
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>>
>>>
>>
> Security is not a choice. The design is not fragile, it is strict and
> correct.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] Unserializes, inheritance and allows_classes

[Marcos Passos]

Hi Marco,

Also: nothing denies an attacker from defining a subtype to your class,
> then passing a malicious instance to your application.


Fact, but it also reveals a fragility in the solution in the sense that one
has to opt between flexible design or security.

Em qui, 17 de jan de 2019 às 22:24, Marco Pivetta 
escreveu:

>
> On Fri, Jan 18, 2019 at 12:49 AM Marcos Passos 
> wrote:
>
>> Hi internals,
>>
>> Today I stumbled upon a limitation when implementing the unserialize
>> method
>> of a serializable class which depends on an abstraction also serializable.
>> Currently, there is no way to unserialize an object specifying a parent
>> class in the allowed_classes option:
>>
>> class SerializableBase implements \Serializable {
>> > }
>> > class SerializableChild extends SerializableBase {
>> > }
>> > class Foo implements \Serializable {
>> >private $dependency;
>> > public function __construct(SerializableBase $dependency) {
>> > $this->dependency = $dependency;
>> > }
>> > public function serialize() : string {
>> >  return \serialize($this->dependency);
>> > }
>> >public function unserialize($data) : void {
>> > $this->dependency = \unserialize($data, ['allowed_classes' =>
>> > SerializableBase::class]);
>> >}
>> > }
>>
>>
>> Is this an intentional limitation?
>>
>>
> Seems expected to me: `allowed_classes` is a whitelist, not a complex
> filter/ruleset.
>
> Also: nothing denies an attacker from defining a subtype to your class,
> then passing a malicious instance to your application.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

[PHP-DEV] Unserializes, inheritance and allows_classes

[Marcos Passos]

Hi internals,

Today I stumbled upon a limitation when implementing the unserialize method
of a serializable class which depends on an abstraction also serializable.
Currently, there is no way to unserialize an object specifying a parent
class in the allowed_classes option:

class SerializableBase implements \Serializable {
> }
> class SerializableChild extends SerializableBase {
> }
> class Foo implements \Serializable {
>private $dependency;
> public function __construct(SerializableBase $dependency) {
> $this->dependency = $dependency;
> }
> public function serialize() : string {
>  return \serialize($this->dependency);
> }
>public function unserialize($data) : void {
> $this->dependency = \unserialize($data, ['allowed_classes' =>
> SerializableBase::class]);
>}
> }


Is this an intentional limitation?

- Marcos

Re: [PHP-DEV] [RFC][Discuss] Covariant return- and contravariant parameter- types

[Marcos Passos]

Supporting `static` return would come in handy to define interfaces for
immutable objects.

Em ter, 27 de nov de 2018 às 19:01, Levi Morrison  escreveu:

> On Tue, Nov 27, 2018 at 11:36 AM Larry Garfield 
> wrote:
> >
> > On Monday, November 26, 2018 3:25:52 PM CST Levi Morrison wrote:
> > > I am happy to announce my latest RFC, [Covariant Returns and
> > > Contravariant Parameters][1], is open for discussion. If you do not
> > > recognize those terms then hopefully the introduction coupled with the
> > > [examples][2] will help. Here is one snippet that demonstrates
> > > covariant return types:
> > >
> > >  > > interface Repository {
> > >   function fetch(int $id): ?Entity;
> > > }
> > >
> > > class UserFactory implements Repository {
> > >   function fetch(int $id): ?UserEntity {
> > > /* Since UserEntity is an Entity, this is now allowed */
> > > /* ... implementation ... */
> > >   }
> > > }
> > > ?>
> > >
> > > Covariant return types and contravariant parameter types are highly
> > > requested features; here are a few of the bug reports:
> > >
> > >   * https://bugs.php.net/bug.php?id=71825
> > >   * https://bugs.php.net/bug.php?id=72442
> > >   * https://bugs.php.net/bug.php?id=75385
> > >   * https://bugs.php.net/bug.php?id=75823
> > >
> > > There is a [preliminary implementation][3] that is available. It will
> > > not be rebased during discussion to allow people to check out the code
> > > and get updates without worrying about it breaking. The code quality
> > > can definitely be improved, and there are still a few todo comments in
> > > the code.
> > >
> > > Please do not discuss the items found in [Future Scope][4] as part of
> > > this thread, which includes discussing types such as `mixed`,
> > > `scalar`, `numeric`, etc.
> > >
> > > I look forward to your feedback, and especially with your
> > > experimentation with the implementation.
> > >
> > > Levi Morrison
> > >
> > >   [1]:
> > >
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
> > > [2]:
> > >
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#exa
> > > mples [3]:
> > > https://github.com/php/php-src/compare/master...morrisonlevi:variance2
> [4]:
> > >
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#fut
> > > ure_scope
> >
> > Looks like fun!
> >
> > Would this also include allowing a return type of `static`, which would
> be
> > useful for the "Return the object that was invoked" case or "return a new
> > instance of the same object" case?  Currently we're limited to `return
> self`,
> > which is, of course, not the same thing and less flexible.
> >
> > --Larry Garfield
>
> It does not. To be honest, I did not think of it until your question.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Discuss] Covariant return- and contravariant parameter- types

[Marcos Passos]

I'm waiting for it for a long time! Thank you for putting effort on this!

Em seg, 26 de nov de 2018 às 19:26, Levi Morrison  escreveu:

> I am happy to announce my latest RFC, [Covariant Returns and
> Contravariant Parameters][1], is open for discussion. If you do not
> recognize those terms then hopefully the introduction coupled with the
> [examples][2] will help. Here is one snippet that demonstrates
> covariant return types:
>
>  interface Repository {
>   function fetch(int $id): ?Entity;
> }
>
> class UserFactory implements Repository {
>   function fetch(int $id): ?UserEntity {
> /* Since UserEntity is an Entity, this is now allowed */
> /* ... implementation ... */
>   }
> }
> ?>
>
> Covariant return types and contravariant parameter types are highly
> requested features; here are a few of the bug reports:
>
>   * https://bugs.php.net/bug.php?id=71825
>   * https://bugs.php.net/bug.php?id=72442
>   * https://bugs.php.net/bug.php?id=75385
>   * https://bugs.php.net/bug.php?id=75823
>
> There is a [preliminary implementation][3] that is available. It will
> not be rebased during discussion to allow people to check out the code
> and get updates without worrying about it breaking. The code quality
> can definitely be improved, and there are still a few todo comments in
> the code.
>
> Please do not discuss the items found in [Future Scope][4] as part of
> this thread, which includes discussing types such as `mixed`,
> `scalar`, `numeric`, etc.
>
> I look forward to your feedback, and especially with your
> experimentation with the implementation.
>
> Levi Morrison
>
>   [1]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
>   [2]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#examples
>   [3]:
> https://github.com/php/php-src/compare/master...morrisonlevi:variance2
>   [4]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#future_scope
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Proposal - Introduce NumberFormat::TYPE_DECIMAL

[Marcos Passos]

Hello everyone!

I would like to propose introducing a new constant
NumberFormat::TYPE_DECIMAL to allow parsing and formatting decimal strings.
This constant would only expose the method parseDecimal
<http://icu-project.org/apiref/icu4c/unum_8h.html#a59870a322f012dc1b9d99cf8a7b708f1>
/formatDecimal
<http://icu-project.org/apiref/icu4c/unum_8h.html#af80334a90b37b2d5c41bd9db00c98687>
from the ICU library. It would bring many possibilities for libraries that
work with precise numbers, such as arbitrary precision math (even BC-math)
and monetary values.

What do you think?

- Marcos Passos

Re: [PHP-DEV] Class name resolution for \array::class

[Marcos Passos]

>
> - It doesn't protect against typos like a constant would, because
> \itn::class will reliably and silently resolve to 'itn' whether or not such
> a class exists.


It's  a good point, I didn't realized that.

Having a ::type pseudo-constant is preferable, indeed. The whole point was
about making it consistent before you stated that this use case become
valid by mistake.

Em seg, 1 de out de 2018 às 10:52, Rowan Collins 
escreveu:

> On Mon, 1 Oct 2018 at 14:30, Marcos Passos 
> wrote:
>
>> Sorry, it looks like I've replied to Marco only.
>>
>> About use case, we use it to specify types in standardized fashion:
>>
>> if (!$value instanceof Foo) {
>>>  throw InvalidArgumentException::unexpectedType($value, Foo::class);
>>> }
>>> if (!\is_int($value)) {
>>> throw new InvalidArgumentException::unexpectedType($value,
>>> \int::class);
>>> }
>>>
>>> $converter->convert($value, \int::class);
>>
>>
>
> This is just obfuscation for no gain, IMO:
>
> - \int::class is 6 characters longer than 'int', and guaranteed to have
> the same value.
> - It doesn't protect against typos like a constant would, because
> \itn::class will reliably and silently resolve to 'itn' whether or not such
> a class exists.
> - It implies that "int" is a class, which it is not; and that the methods
> always take a class name, which they do not.
>
>
>
>> I also said that it might have some benefits for generic types:
>>
>> I don't disagree with you, but it's already supported right now, so what
>>> I'm only proposing to make it consistent.
>>> Looking forward, supporting name resolution for primitive may have some
>>> benefits for generic types
>>> <https://github.com/PHPGenerics/php-generics-rfc/issues/20#issuecomment-407600337>
>>> .
>>
>>
>
> I note that in that discussion, the suggestion of ::type has already come
> up, and given its own thread:
> https://github.com/PHPGenerics/php-generics-rfc/issues/27
>
> In my view, that would make more sense than officially supporting
> "::class" for things other than classes.
>
>
>
>
>> Beside this, deprecating it now would represent a BC break, right?
>>
>
>
> Nit-pick: deprecation is never a BC break; it just implies eventual
> removal, which is.
>
> But yes, outright banning it now would be a BC break. IMO it should have
> been banned at the same time "int", "string", etc were made illegal class
> names (in PHP 7.0), but I can see an argument that our next chance is PHP
> 8.0.
>
> I still think removing it is the right thing to do, however; it only works
> by mistake, as demonstrated by array::class not being supported when the
> feature was first added.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Class name resolution for \array::class

[Marcos Passos]

Sorry, it looks like I've replied to Marco only.

About use case, we use it to specify types in standardized fashion:

if (!$value instanceof Foo) {
>  throw InvalidArgumentException::unexpectedType($value, Foo::class);
> }
> if (!\is_int($value)) {
> throw new InvalidArgumentException::unexpectedType($value,
> \int::class);
> }
>
> $converter->convert($value, \int::class);


I also said that it might have some benefits for generic types:

I don't disagree with you, but it's already supported right now, so what
> I'm only proposing to make it consistent.
> Looking forward, supporting name resolution for primitive may have some
> benefits for generic types
> <https://github.com/PHPGenerics/php-generics-rfc/issues/20#issuecomment-407600337>
> .


Beside this, deprecating it now would represent a BC break, right?

Em seg, 1 de out de 2018 às 10:15, Rowan Collins 
escreveu:

> On Mon, 1 Oct 2018 at 13:24, Marcos Passos 
> wrote:
>
>>
>> You can also see it as a language construct that expects a type at the
>> left-hand side of the name resolution operator. In that sense, primitive
>> types are perfectly valid.
>>
>
>
> While I can see that as an interpretation, it doesn't make a lot of sense:
>
> - the keyword "class" implies that this will always return a class name;
> it is the static equivalent of get_class(), which does not support
> non-objects
> - if instead it was resolving a "type", you might expect it to return the
> same values as gettype(), which for any object is simply the string "object"
> - the main purpose of the feature is to resolve namespace lookups and
> aliases, but basic types are not subject to namespaces; in other words,
> "int::class" can only ever return "int"
>
> As Marco says, if you have a use case where allowing this is helpful,
> please share it, and we can discuss if this, or some new related feature
> (e.g. "array::type"), would be worth supporting.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Class name resolution for \array::class

[Marcos Passos]

Rowan, thank you for sharing your thoughts.

You can also see it as a language construct that expects a type at the
left-hand side of the name resolution operator. In that sense, primitive
types are perfectly valid.

Regards,
Marcos

Em seg, 1 de out de 2018 às 05:45, Rowan Collins 
escreveu:

> On Mon, 1 Oct 2018 at 00:30, Marcos Passos 
> wrote:
>
>> Currently, class name resolution supports all types except an array.
>> https://3v4l.org/OXFMW
>>
>
> It seems to me that the bug is allowing an expression like "int::class" to
> resolve, when "int" is no longer a legal class name.
>
> I suspect the reason "array::class" doesn't work is that it was already a
> reserved word in PHP 5, whereas other types were legal class names. In PHP
> 5, "int::class" can plausibly resolve to the name of an actual class, but
> in PHP 7, it can't, but clearly this part of the grammar wasn't updated to
> reflect that.
>
> The parser is being too forgiving here, I think, and should complain if
> the word before :: is not a valid class name.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

[PHP-DEV] Class name resolution for \array::class

[Marcos Passos]

Currently, class name resolution supports all types except an array.
https://3v4l.org/OXFMW

In fact, it is syntactically invalid since the parser fails to recognize
`array::class` as an array expression:

Parse error: syntax error, unexpected 'array' (T_ARRAY), expecting
> identifier (T_STRING)
> https://3v4l.org/5IOoI


Is possible to change the grammar to support array also?

- Marcos

Re: [PHP-DEV] Interruptions

[Marcos Passos]

Have you tried generators? It looks like you are trying to implement
coroutines.

You can learn more about cooperative multitasking in PHP on this awesome
post written by Nikic:
https://nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html

- Marcos

On Wed, Sep 26, 2018 at 16:47 David Rodrigues 
wrote:

> I do not know if I can get the same result with the current PHP features
> without taking many turns. So I thought of a feature that I'm initially
> calling "interruptions" (similar to those that occur on a CPU).
>
> Nowadays we have the Exceptions, which stop the execution of a function and
> initiate a process of "catch" and treatment of the same. So I thought of
> something similar, but did not break the execution flow, allowing reactions
> to depend on what was happening inside a function.
>
> It would basically work according to the following flow (the square
> brackets number is the execution order):
>
> function sum(int $a, int $b): int {
> [2] interrupts with new SumInterruption($a, $b);
> [5] return $a + $b;
> }
>
> interruptable {
>   [6] $sum = [1] sum(1, 2);
>   [7] printf($sum);
> }
> [3] catch (SumInterruption $interruption) {
>   [4] printf('Calculating: %d + %d = ', $interruption->a,
> $interruption->b);
> }
>
> Using current PHP features I can do like that:
> https://pastebin.com/Bci6BBfi
>
> Note that all code will be executed, and the interpection will only
> redirect temporarily the execution flow to the "catch" block, then will
> back to "sum()" block to return the sum. Like Exceptions, an Interruption
> will traverse the code execution tree until find a interruption catch
> block, but if it doesn't exists, just not will happen (or maybe throw
> InterruptionNotHandledException or something like it).
>
> In one of my real example cases, I have a code that could be manipulated by
> another method. Currently I need argument the self instance to this method,
> so it could run another method from the caller method to make some
> adjustments, which is a bit confuses.
>
> I hope you understand my point, and I am open to discuss that.
>
> Thanks!
>
> --
> David Rodrigues
>

Re: [PHP-DEV] Array max size

[Marcos Passos]

If you are arguing strictly about not knowing what to write on the
documentation, let's move the discussion towards whether it should be
defined or not.

2018-08-01 16:51 GMT-03:00 Sherif Ramadan :

> Right, and therein lies the problem. No one has ever defined this
> behavior. As such, one cannot document what has never been defined.
>
> What you're describing is UNdefined. Undefined things cannot be documented.
>
>
> On Wed, Aug 1, 2018, 3:46 PM Marcos Passos 
> wrote:
>
>> *The point is not about the possibility of crossing the limit of the
>> array, but the need for a definition so one can design a method or function
>> whose behavior aligns with the array capabilities. This need, in fact,
>> became more noticeable from a design point of view since the introduction
>> of the iterable pseudo-type.
>>
>>
>>
>> 2018-08-01 16:44 GMT-03:00 Marcos Passos :
>>
>>> It looks like the limit I mentioned, used by some functions, is
>>> architecture-dependent:
>>> https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288
>>>
>>> Also, that's such a ridiculously large number for the vast majority of
>>>> people using PHP that hardly anyone ever runs into this limit.
>>>
>>>
>>> The point is not about the possibility of crossing the limit of the
>>> array, but the need for a definition is one to design a method or function
>>> whose behavior aligns with the array capabilities. This need, in fact,
>>> became more noticeable from a design point of view since the introduction
>>> of the iterable pseudo-type.
>>>
>>> No one ever said "this is what will happen if a PHP array exceeds 
>>>> size". Until someone does that, I cannot document it.
>>>
>>>
>>> I cannot disagree more with this statement.
>>>
>>> - Marcos
>>>
>>> 2018-08-01 16:29 GMT-03:00 Sherif Ramadan :
>>>
>>>> It's undocumented, because it's considered undefined behavior. PHP
>>>> arrays implicitly store the number of elements internally as an unsigned 32
>>>> bit integer (regardless of architecture). This means that (technically) you
>>>> can't create an array with more than ((2**31) - 1) elements (or
>>>> 2,147,483,647 elements). However, PHP won't actually attempt to stop you
>>>> from doing this! The problem is, once you exceed these number of elements,
>>>> the integer will overflow, causing undefined behavior (all kinds weird
>>>> bugs). So we cannot document behavior that was never defined. No one ever
>>>> said "this is what will happen if a PHP array exceeds  size". Until
>>>> someone does that, I cannot document it. Also, that's such a ridiculously
>>>> large number for the vast majority of people using PHP that hardly anyone
>>>> ever runs into this limit.
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos <
>>>> marcospassos@gmail.com> wrote:
>>>>
>>>>> Whenever you look for more information about the maximum size of an
>>>>> array,
>>>>> you find someone saying that "PHP arrays do not have a maximum size,
>>>>> but
>>>>> the amount of memory available". However, I could not find any excerpt
>>>>> in
>>>>> PHP documentation that supports that.
>>>>>
>>>>> Even if the engine imposes no hard limit on the size of an array, in
>>>>> fact,
>>>>> there an inherent limit that is assumed by some functions, and that is
>>>>> what
>>>>> I would like to suggest making explicit on the documentation. The lack
>>>>> of
>>>>> this definition leads to inconsistencies and leaves several open
>>>>> questions,
>>>>> including:
>>>>>
>>>>>- If no limit exists, then it's conceptually possible to have an
>>>>> array
>>>>>with *PHP_INT_MAX + 1* elements. In that sense, what would be the
>>>>> return
>>>>>of the *\count()*?
>>>>>- The function *range* validates the size of the resulting range
>>>>> against
>>>>>the maximum size of the hash table (defined internally as
>>>>> *HT_MAX_SIZE*),
>>>>>and throw an error if it exceeds that value. Is that the limit?
>>>>>- he function *array_fill*, in contrast, does not rely on
>>>>> *HT_MAX_SIZE*
>>>>>for validating the size of the result. But, why?
>>>>>- The documentation says that omitting the third parameter of
>>>>>array_split is equivalent to \count($array). If the maximum number
>>>>>representable in PHP is *PHP_INT_MAX*, is the max size the same as
>>>>>*PHP_INT_MAX*?
>>>>>
>>>>> There are other examples, but I think these are enough to make the
>>>>> point.
>>>>>
>>>>> My understanding is that the conceptual limit is *PHP_INT_MAX*, as
>>>>> there is
>>>>> no way to represent the size above this value. If so, the interval that
>>>>> represents all possibles indexes for an array is defined as *0 <=
>>>>> index <=
>>>>> PHP_INT_MAX -1*. That definition aligns with all functions that support
>>>>> negative length as *-PHP_INT_MAX* is equivalent to the start of the
>>>>> array.
>>>>>
>>>>> Could you guys please share your thoughts on this topic?
>>>>>
>>>>
>>>
>>

Re: [PHP-DEV] Array max size

[Marcos Passos]

*The point is not about the possibility of crossing the limit of the array,
but the need for a definition so one can design a method or function whose
behavior aligns with the array capabilities. This need, in fact, became
more noticeable from a design point of view since the introduction of the
iterable pseudo-type.



2018-08-01 16:44 GMT-03:00 Marcos Passos :

> It looks like the limit I mentioned, used by some functions, is
> architecture-dependent:
> https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288
>
> Also, that's such a ridiculously large number for the vast majority of
>> people using PHP that hardly anyone ever runs into this limit.
>
>
> The point is not about the possibility of crossing the limit of the array,
> but the need for a definition is one to design a method or function whose
> behavior aligns with the array capabilities. This need, in fact, became
> more noticeable from a design point of view since the introduction of the
> iterable pseudo-type.
>
> No one ever said "this is what will happen if a PHP array exceeds 
>> size". Until someone does that, I cannot document it.
>
>
> I cannot disagree more with this statement.
>
> - Marcos
>
> 2018-08-01 16:29 GMT-03:00 Sherif Ramadan :
>
>> It's undocumented, because it's considered undefined behavior. PHP arrays
>> implicitly store the number of elements internally as an unsigned 32 bit
>> integer (regardless of architecture). This means that (technically) you
>> can't create an array with more than ((2**31) - 1) elements (or
>> 2,147,483,647 elements). However, PHP won't actually attempt to stop you
>> from doing this! The problem is, once you exceed these number of elements,
>> the integer will overflow, causing undefined behavior (all kinds weird
>> bugs). So we cannot document behavior that was never defined. No one ever
>> said "this is what will happen if a PHP array exceeds  size". Until
>> someone does that, I cannot document it. Also, that's such a ridiculously
>> large number for the vast majority of people using PHP that hardly anyone
>> ever runs into this limit.
>>
>>
>>
>>
>> On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos 
>> wrote:
>>
>>> Whenever you look for more information about the maximum size of an
>>> array,
>>> you find someone saying that "PHP arrays do not have a maximum size, but
>>> the amount of memory available". However, I could not find any excerpt in
>>> PHP documentation that supports that.
>>>
>>> Even if the engine imposes no hard limit on the size of an array, in
>>> fact,
>>> there an inherent limit that is assumed by some functions, and that is
>>> what
>>> I would like to suggest making explicit on the documentation. The lack of
>>> this definition leads to inconsistencies and leaves several open
>>> questions,
>>> including:
>>>
>>>- If no limit exists, then it's conceptually possible to have an array
>>>with *PHP_INT_MAX + 1* elements. In that sense, what would be the
>>> return
>>>of the *\count()*?
>>>- The function *range* validates the size of the resulting range
>>> against
>>>the maximum size of the hash table (defined internally as
>>> *HT_MAX_SIZE*),
>>>and throw an error if it exceeds that value. Is that the limit?
>>>- he function *array_fill*, in contrast, does not rely on
>>> *HT_MAX_SIZE*
>>>for validating the size of the result. But, why?
>>>- The documentation says that omitting the third parameter of
>>>array_split is equivalent to \count($array). If the maximum number
>>>representable in PHP is *PHP_INT_MAX*, is the max size the same as
>>>*PHP_INT_MAX*?
>>>
>>> There are other examples, but I think these are enough to make the point.
>>>
>>> My understanding is that the conceptual limit is *PHP_INT_MAX*, as there
>>> is
>>> no way to represent the size above this value. If so, the interval that
>>> represents all possibles indexes for an array is defined as *0 <= index
>>> <=
>>> PHP_INT_MAX -1*. That definition aligns with all functions that support
>>> negative length as *-PHP_INT_MAX* is equivalent to the start of the
>>> array.
>>>
>>> Could you guys please share your thoughts on this topic?
>>>
>>
>

Re: [PHP-DEV] Array max size

[Marcos Passos]

It looks like the limit I mentioned, used by some functions, is
architecture-dependent:
https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288

Also, that's such a ridiculously large number for the vast majority of
> people using PHP that hardly anyone ever runs into this limit.


The point is not about the possibility of crossing the limit of the array,
but the need for a definition is one to design a method or function whose
behavior aligns with the array capabilities. This need, in fact, became
more noticeable from a design point of view since the introduction of the
iterable pseudo-type.

No one ever said "this is what will happen if a PHP array exceeds 
> size". Until someone does that, I cannot document it.


I cannot disagree more with this statement.

- Marcos

2018-08-01 16:29 GMT-03:00 Sherif Ramadan :

> It's undocumented, because it's considered undefined behavior. PHP arrays
> implicitly store the number of elements internally as an unsigned 32 bit
> integer (regardless of architecture). This means that (technically) you
> can't create an array with more than ((2**31) - 1) elements (or
> 2,147,483,647 elements). However, PHP won't actually attempt to stop you
> from doing this! The problem is, once you exceed these number of elements,
> the integer will overflow, causing undefined behavior (all kinds weird
> bugs). So we cannot document behavior that was never defined. No one ever
> said "this is what will happen if a PHP array exceeds  size". Until
> someone does that, I cannot document it. Also, that's such a ridiculously
> large number for the vast majority of people using PHP that hardly anyone
> ever runs into this limit.
>
>
>
>
> On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos 
> wrote:
>
>> Whenever you look for more information about the maximum size of an array,
>> you find someone saying that "PHP arrays do not have a maximum size, but
>> the amount of memory available". However, I could not find any excerpt in
>> PHP documentation that supports that.
>>
>> Even if the engine imposes no hard limit on the size of an array, in fact,
>> there an inherent limit that is assumed by some functions, and that is
>> what
>> I would like to suggest making explicit on the documentation. The lack of
>> this definition leads to inconsistencies and leaves several open
>> questions,
>> including:
>>
>>- If no limit exists, then it's conceptually possible to have an array
>>with *PHP_INT_MAX + 1* elements. In that sense, what would be the
>> return
>>of the *\count()*?
>>- The function *range* validates the size of the resulting range
>> against
>>the maximum size of the hash table (defined internally as
>> *HT_MAX_SIZE*),
>>and throw an error if it exceeds that value. Is that the limit?
>>- he function *array_fill*, in contrast, does not rely on *HT_MAX_SIZE*
>>for validating the size of the result. But, why?
>>- The documentation says that omitting the third parameter of
>>array_split is equivalent to \count($array). If the maximum number
>>representable in PHP is *PHP_INT_MAX*, is the max size the same as
>>*PHP_INT_MAX*?
>>
>> There are other examples, but I think these are enough to make the point.
>>
>> My understanding is that the conceptual limit is *PHP_INT_MAX*, as there
>> is
>> no way to represent the size above this value. If so, the interval that
>> represents all possibles indexes for an array is defined as *0 <= index <=
>> PHP_INT_MAX -1*. That definition aligns with all functions that support
>> negative length as *-PHP_INT_MAX* is equivalent to the start of the array.
>>
>> Could you guys please share your thoughts on this topic?
>>
>

[PHP-DEV] Array max size

[Marcos Passos]

Whenever you look for more information about the maximum size of an array,
you find someone saying that "PHP arrays do not have a maximum size, but
the amount of memory available". However, I could not find any excerpt in
PHP documentation that supports that.

Even if the engine imposes no hard limit on the size of an array, in fact,
there an inherent limit that is assumed by some functions, and that is what
I would like to suggest making explicit on the documentation. The lack of
this definition leads to inconsistencies and leaves several open questions,
including:

   - If no limit exists, then it's conceptually possible to have an array
   with *PHP_INT_MAX + 1* elements. In that sense, what would be the return
   of the *\count()*?
   - The function *range* validates the size of the resulting range against
   the maximum size of the hash table (defined internally as *HT_MAX_SIZE*),
   and throw an error if it exceeds that value. Is that the limit?
   - he function *array_fill*, in contrast, does not rely on *HT_MAX_SIZE*
   for validating the size of the result. But, why?
   - The documentation says that omitting the third parameter of
   array_split is equivalent to \count($array). If the maximum number
   representable in PHP is *PHP_INT_MAX*, is the max size the same as
   *PHP_INT_MAX*?

There are other examples, but I think these are enough to make the point.

My understanding is that the conceptual limit is *PHP_INT_MAX*, as there is
no way to represent the size above this value. If so, the interval that
represents all possibles indexes for an array is defined as *0 <= index <=
PHP_INT_MAX -1*. That definition aligns with all functions that support
negative length as *-PHP_INT_MAX* is equivalent to the start of the array.

Could you guys please share your thoughts on this topic?

Re: [PHP-DEV] Nullable cast (?int)

[Marcos Passos]

Pretty nice idea!

On Tue, Jul 31, 2018 at 22:06 Gabriel Caruso 
wrote:

> >
> > Thanks a lot!
> >
> > 1. I never did a RFC and have no karma to do, so if someone wants to help
> > me with that, I appreciate (contact me directly, then we could publish
> RPC
> > link as reply here).
> >
>
>
> Someone can give you acess to https://wiki.php.net/rfc to you email, so
> you'll be able to write the RFC, no karma need for that.
>
>
> >
> > 2. Too, I could not implementate it, and I don't know if it is a
> > requirement to write a RFC or if it could be done in another moment.
> >
> > 3. What PHP version it should be focused? 7.4, right?
> >
>
> Yes, all new features now should target PHP 7.4. Just write the RFC and
> open the PR at https://github.com/php/php-src and let the process rollout.
>
> Regards,
> --
> Gabriel Caruso
>

Re: [PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(), array_value_last()

[Marcos Passos]

A function like array_offset would be convenient as there is no way to
access the value of an array entry by its index currently. The workaround
is using array_slice, with all the downsides already pointed out.

2018-07-13 20:04 GMT-03:00 Levi Morrison :

> On Fri, Jul 13, 2018 at 4:50 PM Levi Morrison  wrote:
> >
> > On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison  wrote:
> > >
> > > On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno 
> wrote:
> > > >
> > > > Hi,
> > > >
> > > > as the discussion got no new contributions I'd like to start the
> voting
> > > > for the RFC fo add new functions for the handling of outer array
> elements.
> > > >
> > > > https://wiki.php.net/rfc/array_key_first_last
> > > >
> > > > To have a better separation I split up the vote for the functions.
> The
> > > > first vote covers the functions to handle keys: array_key_first() and
> > > > array_key_last(). The second vote covers the corresponding functions
> to
> > > > handle the values: array_value_first() and array_value_last().
> > > >
> > > > As this RFC adds functions but doesn't change the language syntax a
> 50%
> > > > + 1 majority is required for both votes. The votes are open until
> > > > 2018-07-16.
> > > >
> > > > The discussion for this RFC is located at
> > > >
> > > > https://externals.io/message/102245
> > > >
> > > > Regards,
> > > >
> > > > Enno
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > This entire time I felt like this should be possible in pure PHP.
> > > Surely, somewhere, we have this capability already? I searched quite a
> > > few functions but didn't find anything.
> > >
> > > However, the feeling was right. Just moments ago Paul Crovella from
> > > Stack Overflow mentioned to me that `array_slice` uses the terminology
> > > `offset` to refer to the order of the entry rather than its key, so I
> > > went looking. As far as I can tell from the [array_slice
> > > implementation][1] it will not trigger copies and will be efficient if
> > > using -1 to retrieve the last index. We can provide the parameter
> > > `preserve_keys` an argument of true to get both the key and the value.
> > > These functions *are* efficiently implementable in user-land!
> > >
> > > Below is a proof-of-concept for the `array_offset` function [mentioned
> > > by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> > > anyone else responded to this suggestion) that is simply a convenience
> > > wrapper over `array_slice`:
> > >
> > > function array_offset(array $input, int $offset): ?array {
> > > $slice = array_slice($input, $offset, 1, true);
> > > return count($slice) ? $slice : null;
> > > }
> > >
> > > $assoc = ['one' => 1, 'two' => 2, 'three' => 3];
> > > $packd = range(1, 4);
> > >
> > > var_dump(array_offset($assoc, -1));
> > > var_dump(array_offset($packd, -1));
> > >
> > > var_dump(array_offset($assoc, 0));
> > > var_dump(array_offset($packd, 0));
> > >
> > > Of course, the `array_slice` function can be used to build all of the
> > > functions described in the RFC, as well.
> > >
> > > My new opinion is that no new functions are required and that
> > > improving the `array_slice` documentation is all that is necessary. It
> > > currently does not show any examples of it working on associated
> > > arrays, which is probably why none of us (many of us experts) realized
> > > this through this discussion. This is especially true as "offset" in
> > > some other situations really means "key", as in
> > > `ArrayAccess::offsetGet`.
> > >
> > >   [1]: https://github.com/php/php-src/blob/
> b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
> > >   [2]: https://externals.io/message/102245#102322
> >
> > Small correction: Nicolas used the name `array_index`, not
> `array_offset`.
>
> Unfortunately I was too hasty: `array_slice` will iterate over the
> entire input range:
>
> https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b
> 7e1080764d/ext/standard/array.c#L3538-L3552
>
> We could add an case for when `array_slice` uses `-1`. I wonder how
> common this already is. Does anyone have a tool that easily can search
> open source code for usages of functions? I am interested in this
> regardless of the outcome of this RFC.  The documentation for
> `array_slice` should also be updated independently of this RFC as
> well.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>