Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki  wrote:

>
>  I would like to vote to "yes".
> However, RFC does not have benchmark result. Do you have some results?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
I have not run a benchmark on the current implementation but would be happy
to (and also attach that to the results of the RFC, pass or fail). Since
there really isn't a good way to test this exact behaviour against master
(since it doesn't exist), do you have any ideas for a reasonable benchmark?
The only added clock time should be attaching "friended" classes to the
"friending" zend_class_entry and an additional runtime check for
`protected` member access. What about the following:

For master (control):

```
class Readable {
  public $property = 'foo';
}

class Reader {
  public function read(Readable $object) {
echo $object->property;
  }
}

$readable = new Readable();
$reader = new Reader();

// Time the following...
for ($i = 0; $i < 1; $i++) {
  $reader->read($readable);
}
```

For RFC (experiment):

```
class NotReadable {
  friend Reader;

  protected $property = 'foo';
}

class Reader {
  public function read(NotReadable $object) {
echo $object->property;
  }
}

$not_readable = new NotReadable();
$reader = new Reader();

// Time the following...
for ($i = 0; $i < 1; $i++) {
  $reader->read($not_readable);
}
```

If you have any better idea, let me know and I can move forward. Also, if
there is some "standard" benchmark you'd like me to run, please let me know.

Thanks!

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get
there."

Re: [PHP-DEV] [RFC] Typed Properties

[Sara Golemon]

On Fri, Jul 6, 2018 at 4:46 PM, Christoph M. Becker  wrote:
> Why should we have 2 additional alphas?  In my opinion, a single
> additional alpha is sufficient, and it is really important not to add
> yet further features.
>
Because in the best case scenario (with a single extra alpha), the RFC
is ready now, and the vote for it opens immediately.  After two weeks,
we get a yes vote and we'll be right on the edge of ready for
FF/beta1.  Adding that fifth alpha gives us breathing room for
something short of idealized circumstances.

On Sat, Jul 7, 2018 at 5:12 PM, Zeev Suraski  wrote:
> First, it may be a personal thing, but I feel that the flexibility towards 
> adding
> this is very contrasty with the inflexibility shown as we headed towards the
> PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO 
> wrong)
> decision regarding how to implement the non-strict types.
>
Actually, I think Typed Props are being rushed as well, and I'm not
pleased with it, but I can also see the writing on the wall and want
to minimize the impact of that hurry (hence, pushing the timeline out
rather than having things land weeks into the beta cycle).

>  For the record - as I said back then - I think that the right way is to be 
> flexible -
> the dates are just dates, and are - in all honesty - not that important - 
> it’s the severe
> inconsistency that bothers me.
>
I agree that dates are just dates, but blithely eroding the
pre-release cycle without pushing the GA date out isn't saying "dates
are dates", it's saying "RC testing doesn't matter".  I just want 7.3
to get as much baking in time as earlier releases got.

> Secondly, and somewhat related - typed properties isn't a small feature.
> It is, in fact, a pretty huge one.  Making exceptions for a fairly minor 
> feature
> or some extra deprecation is one thing.  Making an exception for something
> as fundamental as that feels wrong.
>
Agreed, and why I haven't decided on a "yes" vote.  Again, I'm not
pushing for this feature, I'm pushing for our pre-release cycle
suffering as little damage as I can manage to protect it from.

> Even though Nikita's proposal and implementation look pretty solid,
> something as fundamental as that should go through a substantial
> active discussion period (which didn't really happen here as it wasn't
> clear whether this was headed for an exceptional 7.3 addition or not) -
>
I'm working on the assumption that Niki still plans to bring this to
vote.  Perhaps he's decide it needs to wait and this whole discussion
of extra alphas is moot.  That's why I sent an email about the
subject.

> and independently - should perhaps go hand-in-hand with fixing the
> flaws of the non-strict types - something we can do in PHP 8.
> If we do the latter, then perhaps, just perhaps, we can introduce it
> hand-in-hand with typed variables - and if we do, it will be sensible
> to do it at the same time and not in a gradual rollout.
>
And that's a decision we need to make, NOW.  We need to know in the
next 10 days if we're going to move forward with a 7.3 that doesn't
contain TP, or if we're going to push out the betas until we can
solidify it.  Waiting to make that decision is making a decision by
default (almost as bad as making the wrong decision).

> Personally, I think even independently of typed variables, typed properties 
> feel like an 8.0 feature, not a 7.x feature.
>
I probably agree with you on that. (Again, still undecided).

-Sara

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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Yasuo Ohgaki]

On Sat, Jul 7, 2018 at 5:26 AM Dustin Wheeler  wrote:

> Hello,
>
> I've let this RFC linger for a long time and finally wrapped up the
> remaining administrative items to put it to vote. This has been
> discussed a few times in the past:
>
> https://externals.io/message/89732
> https://externals.io/message/90311
>
> I would like to open the vote for an RFC to support Class Friendship in
> PHP:
>
> https://wiki.php.net/rfc/friend-classes
>
> The vote ends 2018-07-13 21:00 UTC.
>
>
"Friend" is powerful feature when classes are required to have "tight
coupling",
even if "tight coupling" is bad thing to have in general.

Most obvious use case is "testing classes".
Tests require tight coupling because tests have to know and test class
internals
to perform detailed tests.

With "friend", we can remove A LOT of access methods solely for testing
class.
Less codes means less complexity. Having many codes for tests in production
classes does not make much sense also. Having a lot of getter/setter
methods
for testing is pain and this fact leads developers to write inferior tests.

"Friend" makes UNIT test and Contract Programming much simpler and easier.
Therefore, it helps to develop more robust apps.

Obvious risk is "friend abuse" where "tight coupling" isn't required nor
useful.
Big warning in the doc would be enough to prevent users from shooting their
own foot. There are features like "friend", e.g. $GLOBALS

I understand concerns, however simpler/cleaner production classes without
test only methods and having detailed tests is worth to have.

 I would like to vote to "yes".
However, RFC does not have benchmark result. Do you have some results?

Regards,

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

RE: [PHP-DEV] [RFC] Typed Properties

[Zeev Suraski]

> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Friday, July 6, 2018 10:36 PM
> To: Christoph M. Becker 
> Cc: Nikita Popov ; s...@php.net; Björn Larsson
> ; Dan Ackroyd ;
> Stanislav Malyshev ; Marco Pivetta
> ; PHP internals 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> 
> Just want to be annoying about this since the currently scheduled fork date 
> for
> PHP-7.3 is 11 days off.
> 1/ Do we have *ANY* objections to additional alpha(s) to accommodate Typed
> Props? (I would propose two additional alphas) 2/ Do we actually need to hold 
> a
> formal vote? (If so, that vote should start *now*)

Sara,

I do see a couple of issues here.

First, it may be a personal thing, but I feel that the flexibility towards 
adding this is very contrasty with the inflexibility shown as we headed towards 
the PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO 
wrong) decision regarding how to implement the non-strict types.  For the 
record - as I said back then - I think that the right way is to be flexible - 
the dates are just dates, and are - in all honesty - not that important - it’s 
the severe inconsistency that bothers me.

Secondly, and somewhat related - typed properties isn't a small feature.  It 
is, in fact, a pretty huge one.  Making exceptions for a fairly minor feature 
or some extra deprecation is one thing.  Making an exception for something as 
fundamental as that feels wrong.  

Even though Nikita's proposal and implementation look pretty solid, something 
as fundamental as that should go through a substantial active discussion period 
(which didn't really happen here as it wasn't clear whether this was headed for 
an exceptional 7.3 addition or not) - and independently - should perhaps go 
hand-in-hand with fixing the flaws of the non-strict types - something we can 
do in PHP 8.  If we do the latter, then perhaps, just perhaps, we can introduce 
it hand-in-hand with typed variables - and if we do, it will be sensible to do 
it at the same time and not in a gradual rollout.  Personally, I think even 
independently of typed variables, typed properties feel like an 8.0 feature, 
not a 7.x feature.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Sat, Jul 7, 2018 at 12:09 PM Niklas Keller  wrote:
>
> Hey,
>
> could you please fix the creation date in the RFC? It lists
> 2018-06-27, which would mean that the minimum discussion period
> wouldn't be over, yet, but it's actually been created somewhen last
> year.
>

Ugh, sorry about that! In my rush getting the voting doodle in, I
updated the date as well as a matter of habit.

I've updated the date to 2017-09-21, which was the date I considered
the RFC text finalized. For completeness, the last call for discussion
was almost 9 months ago [1].

1: https://externals.io/message/100743

Thanks for the heads up!

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] Introspection for references

[Nikita Popov]

Hi,

This was brought up in the thread for the typed properties RFC, but I'd
like to split off this discussion.

Before talking about solutions, can the people who need this first outline
what functionality is needed and what it is needed for (and maybe what
workarounds you currently use). E.g. do you only need to know whether
something is a reference, or do you need to know whether two somethings are
part of the same reference, etc. There are probably multiple use cases for
this with different needs.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Typed Properties

[Rowan Collins]

On 06/07/2018 21:57, Nicolas Grekas wrote:



if ((new ReflectionReference($array[$key]))->getRefcount() > 2) {

I just realized that this interface would suffer from a significant
drawback: it would trigger COW when iterating over immutable arrays,
defeating the shared-memory optimization provided by OPcache.


Any implementation of this that acts like a normal function / 
constructor call is going to suffer from the same problems as 
debug_zval_dump: passing a variable from one scope to another will 
change the properties of that variable. If you accept the variable by 
reference, you'll duplicate the data if it's part of a COW set (which 
has nothing to do with OpCache by the way, it's been a core part of the 
engine since at least 5.0); if you accept it by value, you'll duplicate 
the data if it's part of a reference set. Either way, you're going to 
change the refcount on the zval, hence the awkward 2 in Bob's example.


Previous discussions of that function concluded that the only "correct" 
way to implement this would be as a language feature rather than a true 
function - if the compiler issues a specific OpCode, it can pull the 
zval straight out of the symbol table, without interfering with it.


Maybe the two concepts could be combined, and the language feature 
generate a Reflection object? e.g.


$reflection = reflect_variable($var);
if ( $reflection->isReference() ) {
    $types = $reflection->getReferencedTypes();
}




An interface like new ReflectionReference($array, $key) would be free from
the issue. Combined with get_defined_vars() and the (array) operator for
objects, we can inspect any PHP data structure or scope also this way.


Yuck. Even if this solves the issue of supporting both ref and non-ref 
variables, you still end up having to compensate for the wrong refcount, 
and the resultant code would be ugly as sin.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Niklas Keller]

Hey,

could you please fix the creation date in the RFC? It lists
2018-06-27, which would mean that the minimum discussion period
wouldn't be over, yet, but it's actually been created somewhen last
year.

Regards, Niklas

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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dan Ackroyd]

Hi Internals.

To explain my vote, I'm voting no for pretty much the same reasons I
listed before, http://news.php.net/php.internals/90352

The short version of which is:

* 'friendship' is not a good solution for allowing restricted access
to some methods.

* Restricting access to some methods doesn't appear to me to be a big
problem that demands to be solved at the language level with class
friendship. Either solving it at a different level, or some other
solution at the language level, or _just not solving it at all_, would
be a better trade-off to me.

If the vote doesn't approve this RFC, for people who think that
allowing restricted access to some methods is a still a desired thing,
there has been discussion of package level modifiers including things
like visibility and type strictness. To me, a package level solution
would seem to be able to avoid the downsides of 'class friendship' and
give a better fitting tool to solve that problem.

cheers
Dan
Ack

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

Re: [PHP-DEV] Re: [PATCH] Make var_export() output "(object)array(..." instead of"stdClass::__set_state(..." for stdClass

[Andreas Hennings]

I do not disagree, just want to make an observation.

If multiple properties or array keys reference the same instance of
\stdClass, there will be multiple instances with identical values after a
round-trip with var_export() + eval().
This is not necessarily a problem, just something to be aware of.

On Wed, 4 Jul 2018 at 22:33, Christoph M. Becker  wrote:

> On 14.03.2017 at 19:57, Andrea Faulds wrote:
>
> > Since stdClass has no __set_state method, var_export() produces unusable
> > output if given an object of that class. I wrote a patch that would make
> > var_export() produce a cast to object instead, which could be evaluated
> > to get back a stdClass:
> >
> > https://github.com/php/php-src/pull/2420
> >
> > Any thoughts/comments?
> >
> > If you're wondering about whether a __set_state method should be added
> > to stdClass, I posted some thoughts in the pull request discussion
> already.
>
> FTR: If nobody objects, I'll merge this PR into master on 2018-07-12, so
> that it goes into PHP 7.3.
>
> See .
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

[Nikita Popov]

On Thu, Jul 5, 2018 at 12:51 AM, Christoph M. Becker 
wrote:

> On 05.07.2018 at 00:20, Kalle Sommer Nielsen wrote:
>
> > Den tor. 5. jul. 2018 kl. 00.15 skrev Yasuo Ohgaki :
> >
> >> Since the issue is incompatibility between current "continue" and
> "break",
> >> how about provide a tool replace "continue" to "break" where it is
> >> applicable.
> >> (Raise error for invalid "continue" usage also. This would be a bug most
> >> likely.)
> >>
> >> Then there wouldn't be compatibility issue anymore.
> >
> > I like the idea of a tool for such, but I think its better to
> > implement it in some of the static analyzer projects like PHPStan and
> > the like to catch these.
>
> Please note that the RFC has been superseded by
> .
>
> --
> Christoph M. Becker
>

The warning addition in https://github.com/php/php-src/pull/3364 is merged
now and I've marked the original RFC as withdrawn.

Nikita

Re: [PHP-DEV] [RFC] Typed Properties

[Kalle Sommer Nielsen]

Den lør. 7. jul. 2018 kl. 10.47 skrev Björn Larsson :
> I leave this to the judgement of the RMs. I have no opinion myself,
> besides I think it's a good idea to keep the GA date.

I agree, and an additional few weeks will make the release date very
close to the holidays, I think late November/early December is the way
to go about this.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] [RFC] Typed Properties

[Björn Larsson]

On 7/6/2018 9:35 PM, Sara Golemon wrote:

It's up to a combination of internals@ opinion, and RM best-judgement.
I for one, see no issue with pushing FF out (we can do an alpha4, even
an alpha5).  On the other end we have the option of reducing the
number of RCs, or pushing GA by the same delay.  FTR; I'd favor
pushing GA out over shortening the RC cycle, but I wouldn't lose sleep
if we wanted to keep the GA date where it is.


Just want to be annoying about this since the currently scheduled fork
date for PHP-7.3 is 11 days off.
1/ Do we have *ANY* objections to additional alpha(s) to accommodate
Typed Props? (I would propose two additional alphas)
2/ Do we actually need to hold a formal vote? (If so, that vote should
start *now*)


For me that's no and no.


Assuming the answer to both questions is 'No'. I'd like to propose the
7.3 RMs update https://wiki.php.net/todo/php73 to reflect a new
schedule with alpha4 and alpha5 and (provisionally) only four RCs to
maintain the same GA date, but that we should revisit the topic
sometime around the new RC2 date.


I leave this to the judgement of the RMs. I have no opinion myself,
besides I think it's a good idea to keep the GA date.

r//Björn Larsson

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