Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111200
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWy4C0ng5SnEBM6SybcyvO0+MPiHcVcEvDrFG4fNsf2Opw@mail.gmail.com>
 <CAEPJdu=H1j4C8TvdQF=dbMSKUUM=1-3hVkPf1f3WU-hZgKiy8A@mail.gmail.com>
 <VI1PR02MB4703F7E73D33AF4390337E6DE2770@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CAF+90c_SY8Hd5ChPM+EtDU6JZgBCjHOYvSq81QHpz9eLnXSDRA@mail.gmail.com>
 <CAESVnVqy3ovC1a6GaWJOrThYmk=LmbjfEw-+v7muToHEyUsFKw@mail.gmail.com>
 <CAB-BujYqE0gLkzZgnq4aaF=M8ouQrbNnHtE8=8Zy6iSxpeK4Nw@mail.gmail.com>
 <CAB-BujYgACWrfcP0YdQrtP8j7+DZNKO4Tx9Gs4u0b+D_2HST2Q@mail.gmail.com> <DM6PR07MB66188D9FD0B4605D45AF1114F9720@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB66188D9FD0B4605D45AF1114F9720@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Mon, 27 Jul 2020 14:22:11 +0200
Message-ID: <CAB-Bujb=nnB_3prW-bj3uF6HE0BjmYLFTFPuoTtq3LapUXPgQw@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Sara Golemon <pollita@php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	Bob Weinand <bobwei9@hotmail.com>, Benjamin Eberlei <kontakt@beberlei.de>, 
	Chris Riley <t.carnage@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ef0fe505ab6b5fc2"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: andreas@dqxtech.net (Andreas Hennings)

--000000000000ef0fe505ab6b5fc2
Content-Type: text/plain; charset="UTF-8"

On Mon, 27 Jul 2020 at 03:18, tyson andre <tysonandre775@hotmail.com> wrote:

> Hi Andreas Hennings,
>
> > 1. Calls with named arguments can only happen on:
> >   - explicitly named functions (e.g. no call_user_func()).
> >   - constructor calls with an explicitly named class.
> >   - object methods, if the object variable is type-hinted or a type is
> known at compile time.
>
> This proposal would seem to depend on moving opcache into core, among
> other things.
> Depending on how it's implemented, the condition of "a type is known at
> compile time" may also depend on whatever opcache optimization passes were
> enabled,
> which would make the behavior of whether this throws an Error at runtime
> unintuitive to users.
>

Obviously there would need to be a consistent definition about how the type
of a variable should be determined.
And there would need to be a way to determine this at runtime, in case that
opcache is not enabled.
This could be the same system that is responsible for runtime type checks.

Perhaps we should drop the "is known at compile time" and only support
explicit type hints.
Anything we do here should be dumb static analysis, not smart static
analysis.

E.g.

function foo(I $obj) {
  $obj->setColor(color: 'blue');  // Good, based on I::setColor().
  $obj2 = $obj;
  $obj2->setColor(color: 'blue');  // Error, because simple static analysis
cannot determine the type of $obj2.
}


> (e.g. `$a = SOME_OPTIMIZABLE_CONDITION ? new A() : new B();
> $a->someMethod(namedArg: value);`)
>

Any "optimizable condition" would have to be treated like a regular
variable with unknown value.
So in the above case, named arguments would not be allowed.


>
> - `SOME_OPTIMIZABLE_CONDITION` may depend on the php version or
> environment (e.g. `PHP_OS_FAMILY == 'Windows'`)
>
> A recent secondary poll on a rejected RFC I proposed did indicate broad
> interest in moving opcache to php's core,
> but I doubt that'd be done in 8.0 due to the feature freeze, and I also
> doubt optimizations would always be enabled because of the overhead of
> optimization for small short-lived scripts
> ( https://wiki.php.net/rfc/opcache.no_cache#if_you_voted_no_why )
>
> Also, the times when a type is known (with 100% certainty) at compile time
> are known by opcache but unintuitive to users,
> due to the highly dynamic nature of PHP
> (`$$var = 'value'`, references, calls to require()/extract() modifying the
> scope, globals being effectively modifiable at any time, etc.)
> Even for typed properties, the existence of magic methods such as
> `__get()` (e.g. in subclasses) means that the type of $this->prop at
> runtime is uncertain.


> - `__get()` is called if it exists when a declared fetched property (typed
> or otherwise) was unset.
>

Good point.
One thing to note, it seems __get() is only called when the property is
accessed from _outside_.
https://3v4l.org/sY96q (just a snapshot, play around with this as you feel)
I personally don't really care that much about public properties, I could
happily live in a world where named parameters are not available for
objects in public properties.
Or alternatively, we could say that it is the responsibility of the __get()
method to return an object that is compatible with the type hint on the
public property, IF named parameters are used.


Even if all of this does not work, I think the idea still has merit:
Evaluate the parameter names based on a known interface, instead of an
unknown implementation which may come from a 3rd party.
Perhaps a type hint is not the best way to determine this interface..

Greetings
Andreas



>
> Regards,
> - Tyson

--000000000000ef0fe505ab6b5fc2--