Re: [PHP-DEV] [RFC] Userspace operator overloading

[Stanislav Malyshev]

Hi!

> - The individual symbolic operators, with no intrinsic meaning - e.g.
> overloading . for concatenation on strings but dot-product for
> vectors; or a DSL overloading << and >> for "into" and "out of".

Please no. I know it looks fancy and some languages love it, but for a
person not in on the joke reading such code is a nightmare - it's
basically gibberish until you learn all the types and which meaning each
of the types assigns to operators. I mean, I could be maybe talked into
having users overload "+" to mean "add some kind of objects that are
like numbers but not actually integers" because my intuition still works
there even if I don't know the exact type. But if someone thinks it's
super-cool to override + to make it add element to the cache object -
please no. It's way worse than just using plain old ->addObject(). You
may save couple of keystrokes and make your code completely
incomprehensible for people who come after you.

I know DSLs have its niche but I seriously doubt average PHP user
implements a lot of DSLs that are required to work natively on PHP engine.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Userspace operator overloading

[Rowan Tommins]

On 15 February 2020 22:05:52 GMT+00:00, jan.h.boeh...@gmx.de wrote:
>Some discussion points, I can think of, would be the naming of the
>methods
>(maybe naming them after the operator symbol and not the arithmetical
>operation they represent, e.g. __plus instead of __add) or putting the
>methods inside of interfaces like done for ArrayAccess


As I mentioned earlier [1] I think the answers to both of these questions 
depend on a fundamental philosophical question about what you're overloading:

- The groups of operations which exist for built-in types e.g. the arithmetic 
operations overloaded by GMP; or string operations overloaded by an object with 
enhanced Unicode functionality.

- The individual symbolic operators, with no intrinsic meaning - e.g. 
overloading . for concatenation on strings but dot-product for vectors; or a 
DSL overloading << and >> for "into" and "out of".

I think it would benefit the RFC to take a stance on that question, and build 
the feature around it.


[1] https://news-web.php.net/php.internals/108347

-- 
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Rowan Tommins]

On 15 February 2020 20:10:30 GMT+00:00, "Paul M. Jones"  
wrote:
>Hi all,
>
>> On Feb 15, 2020, at 02:01, Larry Garfield 
>wrote:
>> 
>> ... is this proposal intended to supplant HttpFoundation and PSR-7
>... ?
>
>This is question is answered in the RFC introduction


You've cut Larry's question in half there, and in doing so made it seem like a 
repeat, when it is not. The second half of the sentence is this:


> ...or to become a common underpinning that both of them wrap, or to be a 
> third cohabitating implementation in the ecosystem?


I haven't seen you answer that part yet: do you expect existing userland 
libraries to migrate from wrapping $_GET etc to using these built-in wrappers. 
If so, what benefit does it bring those libraries? If not, who is its intended 
audience?


You said previously:

> PDO did not (to my knowledge) "add capabilities which cannot exist in 
> userland or cannot exist in a reasonably performant way".

I think this is a misjudgement, and a relevant one. PDO didn't take 
functionality that existed purely in userland and migrate it to an extension; 
it took functionality that was scattered across a dozen different 
vendor-specific extensions with different naming and calling conventions, and 
centralised it into one more-or-less consistent interface. In doing so, it made 
(or at least tried to make) life easier both for database vendors, who can 
provide a PDO driver and fit into the ecosystem, and library developers, who 
can use PDO as a base and have less vendor-specific code.

Your other examples - date, phar, and session - took common problems that were 
possible to solve in userland but tricky to solve well, and provided a standard 
out-of-the-box implementation.

We already have a unified out-of-the-box implementation for the problem "get 
data out of HTTP request", in the form of superglobals, so neither comparison 
seems apt.

A better comparison might be to features which have been reimplemented multiple 
times, to fix fundamental problems. A recent example is __serialize, but 
interestingly $_GET et al are themselves the third implementation of the 
feature, after "register globals" and the $HTTP_* arrays.

As far as I can see, the RFC mentions two things it fixes about the current 
implementation:

- The current implementation is not OO. That's not really surprising, since PHP 
is not a purely OO language, and treats OO as a matter of style - to the extent 
of providing hybrid object-procedural APIs like date and mysqli.

- The current implementation is based on global state. This is definitely 
something that would be good to fix, but you can do almost as much in that 
direction as the RFC by writing "$get=$_GET; unset($_GET);" The hard problem is 
that the entry point for a request is in global scope, not a main() or 
handleRequest() function. Introducing these objects as part of a new calling 
convention for PHP scripts would definitely add value, and make them a true 
replacement for the superglobals, but that would be a very different RFC.


However well designed this extension is within itself, I think it needs a 
stronger description of who should use it and why.


Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] Re: [RFC] Userspace operator overloading

[Mark Randall]

On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote:

Hi internals,
What do you think about the RFC?


"If an operator is used with an object that does not overload this 
operator, an NOTICE is triggered, which gives the user a hint about the 
method that has to be overloaded. For backward compatibility objects, 
which do not overload the operator, are converted to integer 1 (current 
behavior)."


N :( Notices are the enemy of all that is great and good.

If operator overloading is going to become a first-class feature then it 
should be treated as such, and attempting overloading operators on 
objects that don't have the relevant method available should trigger an 
Error.


--
Mark Randall
marand...@php.net

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

Re: [PHP-DEV] [RFC]

[Dik Takken]

On 15-02-2020 13:07, Manuel Canga wrote:
> Do you think it is worth creating an RFC page about :: function ? I say that 
> because I see that there are many voices against of :: function

 Let us go back to the start of this thread. Your idea was to simplify

array_map('\My\I18N\i18n_translate', $array)

to

array_map(i18n_translate::func, $array)

Then the discussion took the topic one level deeper. In your examples,
you seek a better way to pass a function as callable. In PHP a callable
can be:

1. a string
2. an array
3. a closure

Then it was suggested that a short syntax to wrap the function into a
closure is more useful. Using strings to refer to functions has
consistency issues and the proposed ::func does not solve them. Also,
the array syntax for referring to methods could use a better alternative.

All things considered, I think the originally proposed feature, using
::func to get the function name, has limited use.

Having a ::func (or ::function or ::fn) return a closure might be
somewhat controversial and there is no consensus about the name. The
only way to know how this will be received is to write an RFC and call
for a vote.

My own guess would be that an 'enclosure' construct along the lines of

array_map({i18n_translate}, $array)
array_map({$object->method}, $array)

has better chances of succeeding but you never know what happens.
Perhaps you could team up with Michał and use the feedback from this
thread to produce an RFC.

Regards,
Dik Takken

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

Re: [PHP-DEV] [RFC]

[Dik Takken]

On 11-02-2020 16:27, Levi Morrison via internals wrote:
> I have three immediate thoughts:
> 
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.

Note that even though these do not introduce a new keyword it does mean
that either of these would need to become reserved class constant names
just like 'class'. Otherwise foo::fn or foo::function is ambiguous when
both a function and a class named 'foo' are in scope.

Regards,
Dik Takken

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

Re: [PHP-DEV] [RFC]

[Dik Takken]

On 11-02-2020 12:13, Manuel Canga wrote:
> My proposal is ":func" in order to avoid full namespace in callback of
> functions. E.g:
> 
> use function \My\I18N\i18n_translate;
> 
> $mapped_array = array_map(i18n_translate::func, $array);

Something that did not occur to me before: Seeing the scope resolution
operator being used on something that is not a class or object looks
strange to me. Especially given the resemblance with the built-in
'class' constant that classes have, this looks like functions being used
as if they are classes...

Regards,
Dik Takken

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

[PHP-DEV] [RFC] Userspace operator overloading

[jan.h.boehmer]

Hi internals,

based on the discussions here (https://externals.io/message/108300) and here
(https://github.com/php/php-src/pull/5156), I have created a proper RFC for
userspace operator overloading:
https://wiki.php.net/rfc/userspace_operator_overloading

The main differences to my original concept, is the removed __compare()
method (comparison overloading is a complex topic and should be handled in a
different RFC) and the possibility to signal that the operator handler does
not support the given types (by typehints or returning a special value).
This way, only one of both objects has to know about the other type. This
should expand the use case of operator overloading compared to my old
concept.

What do you think about the RFC?

Some discussion points, I can think of, would be the naming of the methods
(maybe naming them after the operator symbol and not the arithmetical
operation they represent, e.g. __plus instead of __add) or putting the
methods inside of interfaces like done for ArrayAccess (But I don’t see any
advantage in doing so, as it is very difficult grouping different operators
in a single interface usefully. Also, operators can accept and return
different types, so there is no real common interface between classes you
could rely on).
Furthermore, maybe the idea of allowing operator overloading in general
should be discussed as it is sometimes considered an anti-pattern (e.g. the
usage of '<<' for outputting a string in C++). On the other hand there are
many languages and libraries where operator overloading is used successfully
(e.g. numpy in Python).

Regards,
Jan Böhmer

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M. Jones]

Hi all,

> On Feb 15, 2020, at 02:01, Larry Garfield  wrote:
> 
> ... is this proposal intended to supplant HttpFoundation and PSR-7 ... ?

This is question is answered in the RFC introduction; quoting from there:

The SQLite “about” page says, “Think of SQLite not as a replacement
for Oracle but as a replacement for fopen().”

https://www.sqlite.org/about.html

Likewise, think of this RFC not as a replacement for HttpFoundation
or PSR-7, or as a model of HTTP messages, but as an object-oriented
alternative to superglobals, header(), setcookie(), setrawcookie(),
and so on.


> PDO was mentioned previously as a model.

I did not mention PDO as "a model". I mentioned PDO (along with other 
extensions) to illustrate a counter-argument to objections based on the 
availability and comparability of userland implementations. The 
counter-argument summary was:

That's not to say "because PDO was allowed into core, this RFC must
therefore be allowed into core" but to say "those objections alone
were not a barrier to PDO, so they alone should not be a barrier to
this RFC".

The argument, and my counter-argument, are here: 



-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] Allow null variables to be decremented

[Rowan Tommins]

On 15/02/2020 18:21, Mark Randall wrote:

I'm not so sure...

That incrementing a null works at all is a painful part of the 
language spec that I would argue needs flushing down the toilet, 
rather than further reinforcing. 



The problem then is, where do you stop? There are dozens of places where 
null values are coerced to the correct type, and changing them all would 
be a huge BC break.


I think it would be perfectly fine to fix the current bug - that it's 
completely inconsistent in leaving the variable unchanged - even if we 
later decide to deprecate the whole thing.



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] Allow null variables to be decremented

[Rowan Tommins]

On 15/02/2020 18:11, tyson andre wrote:

My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g. 
become `-1`).
It might break some code, but that code was probably incorrect.



Yep, this is precisely the way I see it.


--
Rowan Tommins (né Collins)
[IMSoP]

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

[PHP-DEV] Re: Allow null variables to be decremented

[Mark Randall]

On 15/02/2020 17:44, Rowan Tommins wrote:
There is currently an odd inconsistency when using the decrement 
operator on a null variable:


I'm not so sure...

That incrementing a null works at all is a painful part of the language 
spec that I would argue needs flushing down the toilet, rather than 
further reinforcing.


I recon the required precursor to doing so is erroring on undefined 
variables, which I suspect accounts for about 99% of increment-on-nulls.


The majority are in favour (56%) but not the supermajority necessary - 
Athough there's an argument to be made that a supermajority may exist in 
a straight up or down vote rather than a 3-way 
(https://wiki.php.net/rfc/engine_warnings).


So on one hand, consistency is good.

On the other hand, being consistently bad is still being bad.

--
Mark Randall
marand...@php.net

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

Re: [PHP-DEV] Allow null variables to be decremented

[tyson andre]

My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g. 
become `-1`).
It might break some code, but that code was probably incorrect.

Out of scope of the proposed RFC, but this reminds me of a similar issue:
Currently, the `++` and `--` operators do nothing to arrays or objects,
not even emitting a notice or changing the value.
I see that `++` on typed properties/references can already throw a TypeError 
for integer overflow,
so it might make sense to also start throwing a TypeError for `++` on objects 
(without numeric operation handlers) and arrays.

I'd thought earlier that emitting a notice instead of throwing a TypeError for 
arrays/objects might negatively limit the optimizations opcache can do
because error handlers can have side effects.
But it looks like I'd just have to allow inferring that MAY_BE_OBJECT and 
MAY_BE_ARRAY
could have side effects for the INC/DEC opcodes in `may_have_side_effects()` in 
ext/opcache/Optimizer/dce.c.

(If your RFC ends up emitting warnings/notices, it would need to check for 
MAY_BE_NULL|MAY_BE_UNDEF in dce.c, I think.)

Would there be any interest in emitting a warning or deprecation warning for 
objects/arrays starting in php 8.0?

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

[PHP-DEV] Allow null variables to be decremented

[Rowan Tommins]

Hi all,

There is currently an odd inconsistency when using the decrement 
operator on a null variable:


$a = null; $a=$a+1; // int(1)
$a = null; $a+=1; // int(1)
$a = null; ++$a; // int(1)

$a = null; $a=$a-1; // int(-1)
$a = null; $a-=1; // int(-1)
$a = null; --$a; // null

I would like to propose changing this behaviour for PHP 8, so that --$a 
would give int(-1), as I believe it is simply a long-standing bug.



This has been raised as a bug at least three times [1][2][3] but closed 
as documented behaviour / too much of a BC break. It is documented in 
the manual, but with no explanation of why it should work that way. [4]


I would be interested in any explanations of why it might be intended 
behaviour, or ways in which people might be relying on the current 
behaviour.


A proposal to change the behaviour was included in a wider RFC about 
standardising increment and decrement behaviour, but it never got beyond 
draft status. [5] I would prefer not to reopen that wider debate, but 
focus on this single issue.


As far as I can see, the change would be to add a "case IS_NULL" branch 
to decrement_function in zend_operators.c to match the one in 
increment_function. [6]



I will happily write up an RFC to formalise this, but wanted to gather 
people's immediate thoughts first.



Links:
[1] https://bugs.php.net/bug.php?id=20548
[2] https://bugs.php.net/bug.php?id=25674
[3] https://bugs.php.net/bug.php?id=41690
[4] https://www.php.net/manual/en/language.operators.increment.php
[5] https://wiki.php.net/rfc/normalize_inc_dec
[6] 
https://php-lxr.adamharvey.name/source/xref/master/Zend/zend_operators.c#2359



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] [RFC]

[Larry Garfield]

On Sat, Feb 15, 2020, at 6:07 AM, Manuel Canga wrote:
> 
>   En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield 
>  escribió 
>  > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
>  > 
>  > > Maybe, bettern fn:  * fn(callable $to_clsoure ): *closure ?
>  > > 
>  > > I know fn is used in arrow functions. However, for that same 
> reason fn is
>  > > the most convenient.
>  > > 
>  > > Using dik examples( by the way, they are brilliant ):
>  > 
>  > Point of order: The Stats analyzer examples were from me, not Dik. 
> :-)  They're taken from one of the monad chapters in the book I'm 
> working on.
>  > 
>  > --Larry Garfield
>  > 
> 
> By the way...the following is for folks in internals:
> 
> Do you think it is worth creating an RFC page about :: function ? I say 
> that because I see that there are many voices against of :: function

There seems to be little pushback on the idea of a better way to name/reference 
functions, so an RFC page for that seems reasonable.  What the syntax is, 
that's still in heavy bikeshed territory, so maybe don't name the RFC based on 
the implementation detail yet. :-)

I'd love to get some input from Nikita or Dimitry or someone else with way more 
parser experience on how feasible any of the options discussed so far would be; 
if some are vastly more straightforward than others, that carries a lot of 
weight.

--Larry Garfield

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

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Nikita Popov]

On Fri, Feb 14, 2020 at 7:30 PM Rowan Tommins 
wrote:

> On Fri, 14 Feb 2020 at 16:33, Nikita Popov  wrote:
>
> > This constructor will initialize the corresponding properties. Now, the
> > behavior that would make most sense to me (if extension of the class is
> > allowed) is that MyPhpToken::getAll() is going to create the new tokens
> > based on "new MyPhpToken($id, $text, $line, $pos)". If we mark the
> > constructor final, then we could hardcode the construction behavior of
> the
> > base class without introducing any kind of weird rules, it would be just
> > the usual language semantics.
> >
>
>
> It's worth noting that this is how ext/simplexml works: the $class
> parameter of simplexml_load_string and simplexml_load_file must be the name
> of a class that inherits from SimpleXMLElement, and an instance of that
> class will be constructed for each element of the document. The constructor
> of SimpleXMLElement is final, so the internal initialisation logic doesn't
> have to actually call it, it can just initialise the private state
> directly.
>

Thanks for pointing that out, I wasn't aware that SimpleXMLElement is
already using this pattern. Given that, I've updated the RFC to go with
that option now.

Nikita

Re: [PHP-DEV] [RFC] get_debug_type

[Nikita Popov]

On Sat, Feb 15, 2020 at 3:33 PM Mark Randall  wrote:

> Greetings,
>
> I offer a short RFC to add a new function, get_debug_type, which would
> return the type name of a variable, automatically resolving the class
> name in the event of it being an object.
>
> Unlike gettype, this function will return the true name of scalar
> types, rather than their aliases, thus get_debug_type will return
> "int" rather than "integer" etc.
>
> https://wiki.php.net/rfc/get_debug_type
>
> Mark Randall
> marand...@php.net
>

Can you please add some examples for the behavior? Preferably the precise
output for all primitive types, for classes and for anonymous classes.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Máté Kocsis]

Hi Rowan,

I'm also on the opinion that making the mixed type the (implicit) default
is not a good idea.

However, I believe the uninitialized state is useful, what's more, it was
unavoidable
in order to properly support non-nullable object properties. But I don't
want to make
a case for this decision as it's too late now. :)

> Immutable properties, and eventually immutable objects, however, are
something I'd be very interested to see.

I am happy to hear!

Máté Kocsis
.

Rowan Tommins  ezt írta (időpont: 2020. febr. 15.,
Szo, 0:07):

> On 14/02/2020 13:42, Máté Kocsis wrote:
> > Maybe only if our long-term goal would be to deprecate/remove
> > non-typed properties and implicit initialization altogether in favour of
> > mixed type and implicit uninitialization...
>
>
> Can I just leave an "ugh, please no" on this part. I remain of the
> opinion that the introduction of the "uninitialised" state was a huge
> mistake, and we should be actively working towards making it
> unnecessary, not building more features that rely on it.
>
>
> Immutable properties, and eventually immutable objects, however, are
> something I'd be very interested to see.
>
>
> Regards,
>
> --
> Rowan Tommins (né Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] [RFC] get_debug_type

[Mark Randall]

Greetings,

I offer a short RFC to add a new function, get_debug_type, which would
return the type name of a variable, automatically resolving the class
name in the event of it being an object.

Unlike gettype, this function will return the true name of scalar
types, rather than their aliases, thus get_debug_type will return
"int" rather than "integer" etc.

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

Mark Randall
marand...@php.net

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

Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Máté Kocsis]

Hi Larry,

I admit that this flag is not too interesting, but I believe it still has
its own merit. I can imagine that the flag could play well with property
accessors as well, however,
in my opinion, the main use-case of final properties generally doesn't
involve setters/set accessors.

> In that case, "final" or "lazy" or "locked" would be reasonable names;
read-only and immutable are misleading, as it's really write-once, not
read-only, not truly immutable.

In the meanwhile, I realized that
- "immutable" is simply not true in case of resource and (non-immutable)
object properties
- "readonly" is probably somewhat better, but still not always true in case
of lazy initialization
- "final" seems ok, but it would probably be a better fit for a feature
that would prevent a property to be overwritten (similarly to "final" for
methods)

So I think "final" should only be chosen if we don't want to restrict
property overwriting later. Otherwise, we could use also "locked" or
"sealed" (inspiring from C#).

> As for references and untyped final properties...  Just don't go there.
Require a final property to be non-reference and typed.

So it's essentially what Marco also suggested... Unfortunately, I didn't
exactly get the idea first (I focused too much on the mixed type), but
restricting final to typed properties now
seems reasonable. :) But let me collect the possibilities that I've thought
about so far:
- do not implicitly initialize untyped final properties: although I liked
this idea first, now it feels a bit unintuitive
- add support for mixed, and implicitly convert untyped final properties to
this type: unintuitive
- require final properties to be explicitly initialized before object
instantiation finishes: complicated, makes lazy initalization/proxying
difficult/impossible
- require final properties to be typed: looks straightforward

> I do not foresee untyped properties ever going away

Although I tend to declare types everywhere I can, I also believe we should
leave gradual typing intact.

Thank you very much for the feedback!

Máté Kocsis


Larry Garfield  ezt írta (időpont: 2020. febr. 15.,
Szo, 9:18):

> On Fri, Feb 14, 2020, at 7:22 AM, Máté Kocsis wrote:
> > Hi Internals,
> >
> > I'd like to propose the idea of adding support for
> immutable/final/readonly
> > properties in PHP 8.
> >
> > My plan is to add a new immutable/final/readonly (the name is up for
> > debate) property modifier to the language so that these kind of
> properties
> > could only be initialized but not modified afterwards. Unlike how final
> > properties in Java work, I think it would be beneficial to allow lazy
> > initialization of these properties after object construction have taken
> > place. Currently, I'm in favour of using final or readonly, but not yet
> > very sure.
> >
> > I'll write a proper RFC in the following days/week. My clear intent with
> > final properties is to pave the road for immutable objects for which I
> have
> > a POC pull request open (but I haven't pushed all my work yet).
> >
> > So far, my biggest question (apart from the name) have been how non-typed
> > properties should behave: as they are implicitly initialized to null if
> > they don't have an explicit default value (while typed properties remain
> > uninitialized), further modifications would be impossible to do on them -
> > which would make non-typed final properties almost useless. Nikita
> > suggested to just avoid their initialization, but I'd be curious about
> > other ideas as well.
> >
> > Thanks,
> > Máté Kocsis
>
> My concern is that a simple read-only/final "flag" is a very limited
> feature set.  I'd still love for us to revisit property accessors at some
> point (if the performance issues could be resolved), and I fear that
> layering that *and* a read-only flag together would result in... much
> complex weirdness.  (Technical term.)
>
> That said, were such a feature to be added, I would strongly recommend
> making them able to be defined in terms of an expression, or possibly a
> callable/anon function, with no explicit setting allowed.  To wit:
>
> class Foo {
>
>   protected string $firstName;
>   protected string $lastName;
>
>   protected function getFullName() { return $this->firstName .
> $this->lastName; }
>
>   // And then one of these options:
>
>   public final string $fullName = $this->firstName . $this->lastName;
>
>   public final string $fullName = fn() => $this->firstName .
> $this->lastName;
>
>   public final string $fullName = $this->getFullName();
> }
>
> That would allow for their complete definition in one location, make it
> clear how they're derived, etc.  They essentially become an auto-memoizing
> method (which suits me just fine).  Their value would potentially change
> depending on when it's first called depending on the other values in the
> object, but that's no different than if they were simply "set" from an
> arbitrary location.  The potential for unpredictable semi-non-determinism
> is the 

Re: [PHP-DEV] [RFC]

[Manuel Canga]

  En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield 
 escribió 
 > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
 > 
 > > Maybe, bettern fn:  * fn(callable $to_clsoure ): *closure ?
 > > 
 > > I know fn is used in arrow functions. However, for that same reason fn is
 > > the most convenient.
 > > 
 > > Using dik examples( by the way, they are brilliant ):
 > 
 > Point of order: The Stats analyzer examples were from me, not Dik. :-)  
 > They're taken from one of the monad chapters in the book I'm working on.
 > 
 > --Larry Garfield
 > 

By the way...the following is for folks in internals:

Do you think it is worth creating an RFC page about :: function ? I say that 
because I see that there are many voices against of :: function

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

Re: [PHP-DEV] [RFC]

[Manuel Canga]

  En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield 
 escribió 
 > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
 > 
 > > Maybe, bettern fn:  * fn(callable $to_clsoure ): *closure ?
 > > 
 > > I know fn is used in arrow functions. However, for that same reason fn is
 > > the most convenient.
 > > 
 > > Using dik examples( by the way, they are brilliant ):
 > 
 > Point of order: The Stats analyzer examples were from me, not Dik. :-)  
 > They're taken from one of the monad chapters in the book I'm working on.
 > 
 > --Larry Garfield


Oops!, sorry Larry!. Then you book will be securily a great book.

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

Re: [PHP-DEV] [RFC]

[Larry Garfield]

On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:

> Maybe, bettern fn:  * fn(callable $to_clsoure ): *closure ?
> 
> I know fn is used in arrow functions. However, for that same reason fn is
> the most convenient.
> 
> Using dik examples( by the way, they are brilliant ):

Point of order: The Stats analyzer examples were from me, not Dik. :-)  They're 
taken from one of the monad chapters in the book I'm working on.

--Larry Garfield

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

Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Larry Garfield]

On Fri, Feb 14, 2020, at 7:22 AM, Máté Kocsis wrote:
> Hi Internals,
> 
> I'd like to propose the idea of adding support for immutable/final/readonly
> properties in PHP 8.
> 
> My plan is to add a new immutable/final/readonly (the name is up for
> debate) property modifier to the language so that these kind of properties
> could only be initialized but not modified afterwards. Unlike how final
> properties in Java work, I think it would be beneficial to allow lazy
> initialization of these properties after object construction have taken
> place. Currently, I'm in favour of using final or readonly, but not yet
> very sure.
> 
> I'll write a proper RFC in the following days/week. My clear intent with
> final properties is to pave the road for immutable objects for which I have
> a POC pull request open (but I haven't pushed all my work yet).
> 
> So far, my biggest question (apart from the name) have been how non-typed
> properties should behave: as they are implicitly initialized to null if
> they don't have an explicit default value (while typed properties remain
> uninitialized), further modifications would be impossible to do on them -
> which would make non-typed final properties almost useless. Nikita
> suggested to just avoid their initialization, but I'd be curious about
> other ideas as well.
> 
> Thanks,
> Máté Kocsis

My concern is that a simple read-only/final "flag" is a very limited feature 
set.  I'd still love for us to revisit property accessors at some point (if the 
performance issues could be resolved), and I fear that layering that *and* a 
read-only flag together would result in... much complex weirdness.  (Technical 
term.)

That said, were such a feature to be added, I would strongly recommend making 
them able to be defined in terms of an expression, or possibly a callable/anon 
function, with no explicit setting allowed.  To wit:

class Foo {

  protected string $firstName;
  protected string $lastName;

  protected function getFullName() { return $this->firstName . $this->lastName; 
}

  // And then one of these options:

  public final string $fullName = $this->firstName . $this->lastName;

  public final string $fullName = fn() => $this->firstName . $this->lastName;

  public final string $fullName = $this->getFullName();
}

That would allow for their complete definition in one location, make it clear 
how they're derived, etc.  They essentially become an auto-memoizing method 
(which suits me just fine).  Their value would potentially change depending on 
when it's first called depending on the other values in the object, but that's 
no different than if they were simply "set" from an arbitrary location.  The 
potential for unpredictable semi-non-determinism is the same, or possibly 
better this way.

(In that case, "final" or "lazy" or "locked" would be reasonable names; 
read-only and immutable are misleading, as it's really write-once, not 
read-only, not truly immutable.  I suppose then an "immutable object" would be 
one in which all properties are either final/lazy/locked or set by the 
constructor only.)

There was a thread a few weeks ago on "lazily derived constants" that probably 
has some interesting thoughts as well, though of course this would be 
property-like syntax, which is fine.

As for references and untyped final properties...  Just don't go there.  
Require a final property to be non-reference and typed.  I do not foresee 
untyped properties ever going away (too much legacy code, plus they are legit 
useful at times), but that doesn't mean every conceivable property variant ever 
needs to support them.  Requiring that a final property be typed non-reference 
seems entirely reasonable to me.

--Larry Garfield

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Larry Garfield]

On Fri, Feb 14, 2020, at 10:47 AM, Benjamin Morel wrote:
> >
> > What about $query and $body? That would be closer to the terminology
> > used in HTTP RFCs.
> 
> 
> 
> The problem is that $body is typically used to get the raw message body as
> a string or stream.
> I was thinking more something along the lines of $bodyParams, which is more
> verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*.
> 
> — Benjamin

Data point:

In PSR-7, the names used are:

- queryParams: The query string values.
- parsedBody: The body of the message, converted to a meaningful value. If the 
request type is a form, then it MUST be equivalent to $_POST.  If not, it's up 
to the particular implementation to determine what "parsed" means.  (Eg, 
parsing a JSON body of a POST into some domain object, or whatever.)
- The raw body is a stream called "body", or rather an OOP wrapper around a 
stream since PHP's native stream interface is fugly.
- There's specific handling for uploadedFiles, too.

cf: https://www.php-fig.org/psr/psr-7/

To the earlier point about existing implementations, while there are a myriad 
of older, custom implementations of abstractions around superglobals, there's 
only two that are not decade-old proprietary implementations: HttpFoundation 
and PSR-7.  Those are, realistically, the only implementations that matter.  
Anything else would be on the same order of magnitude effort to port to one of 
those as to port to this proposal.  In a meaningful sense, those are the only 
"existing competition".  Both also have robust ecosystems that make leveraging 
them in an entirely custom app pretty straightforward.

(Whatever your feelings of the technical merits of either design, that's the 
current state-of-the-market.)

Which therefore begs the question, is this proposal intended to supplant 
HttpFoundation and PSR-7, or to become a common underpinning that both of them 
wrap, or to be a third cohabitating implementation in the ecosystem?

It doesn't seem robust enough to supplant both of them entirely, there's little 
value to either HttpFoundation or PSR-7 to rewrite their guts to wrap this 
object (though it's easier for PSR-7, as an interface, for someone to write a 
new implementation of it than for HttpFoundation), which would mean we'd end up 
with a 3rd in-the-wild implementation for user space to keep track of.

I am unclear how that is a market win.

PDO was mentioned previously as a model.  Yes, there were many user-space 
implementations prior to PDO.  PDO effectively supplanted and obsoleted them.  
However... PDO was also never thought-through enough or robust enough to be 
used directly, spawning a whole new ecosystem of PDO++ libraries that people 
actually use (Doctrine, Eloquent, Drupal's DBTNG, Aura.sql, to name but a few). 
 So, not the full win people were hoping for.  If that pattern holds, we'd end 
up with... a new generation of this-RFC++ wrappers that still abstract it away 
yet aren't compatible with each other.

That said, PDO did have the advantage of at least partially unifying disparate 
SQL APIs.  There really aren't multiple incompatible HTTPs to abstract over the 
way there is for SQL backends, so the analogy is somewhat weak either way.

--Larry Garfield

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