[RFC][Vote] Typed Properties View as Markdown

Am 10.06.2016 um 16:24 schrieb Levi Morrison levim@php.net:

Hi,

I hardly worked on implementation of this patch for a week, but I still don't like it.

It makes 15% slowdown on each property update in existing PHP code (without types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest version of the patch).

-1.

Thanks. Dmitry.

---

From: Joe Watkins pthreads@pthreads.org
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe
To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.
Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 cache utilization and the number of executed instructions for a runtime-cached ASSIGN_OBJ is very small. Where even 4 additional instructions make significant difference.
The current fast-path of ASSIGN_DIM is about 40 instruction, so 15%
slowdown comes exactly from this additional 4 instructions and
additional memory read.

The 0.1% slowdown of WP and MW are painting a much more realistic (aka real-world) image. And as the RFC writes, "may be caused not by the additional checks but by the worse CPU cache utilization, because the size of PHP code was increased on 40KB".

Yes, this is my words :)

These micro-benches are really insignificant, especially as it is trivial (in tight loops) to work on a local CV and only assign it later to the property.
they show the effect of the patch on the affected operations, and the
shown slowdown is significant.
Of course this doesn't affect WP significantly, because the whole
ASSIGN_OBJ cost in the app is less than 1%.
So we slowdown this ~1% on ~15% and got ~0.1% cumulative slowdown.

Thanks. Dmitry.

This IMO is really voting no for the wrong reasons...

Bob

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.
I don't see any big value in this feature.
Most framework access their properties through getters and setters
anyway.
They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected
speedup, doesn't make any sense for me.

Thanks. Dmitry.

Needing an explicit getter and setter (and the overhead of the function
call) just for type checking is a bug this feature would obviate. If
the only value of the getter/setter is type safety, then you're better
off not using them. (There are other reasons to have getters and
setters, and I'd still love to see the property accessor RFC reborn, but
that's a separate issue.)

Additionally, typed properties provides a terser, more self-documenting
way of communicating the property type and thus expected behavior. I've
written several doctrine classes, for instance, that are 5 lines of
properties and 30 lines of getters/setters/docs boilerplate. If that
boilerplate can be reduced or eliminated, that's a win.

It also provides better introspection capabilities for ORMs and similar
serialization tools. Yes, in some cases richer data than this RFC
provides is helpful but not always. In many cases this would be
sufficient to build automated safety into automated tools. (ORMs,
serializers, validators that now don't need to be written at all, etc.)

That seems like a worthwhile trade-off for a <1% performance difference
in a real-world application.

--Larry Garfield

If I had to implement type-checked properties in plain PHP, I would do
something like this...

/**

• @property int $price
  */
  class Product
  {
  private $_price;

  public function __set($name, $value) {
  if ($name === "price") {
  if (!is_int($value)) {
  throw new UnexpectedValueException("...");
  }
  $this->_price = $price;
  $this->_price = $value;
  return;
  }
  throw new RuntimeException("undefined property {$name}");
  }

  public function _get($name) {
  return $this->{"{$name}"};
  }
  }

I'm with you on not totally understanding the internals, but ...

var $_price;
Added code to handle the access restrictions, so checks have to be made
on just how $this->_price is accessed.
In my book, the __set function validates range as well as checking so
value is of the right type and any range error can be handled at the
right point. However if you add 'int' to the private then this now adds
a check to see if there IS a type restriction on the 'var' in addition
to access restriction.
Checks for 'strict' come in here as well?
But I still see a lot more cases where the 'is_int' checks are needed in
the normal flow prior to any ACTUAL assignment to the typed property. SO
it makes a lot more sense to me that '$this->_price = $value;' either
does the job of validation fully, or does not do it at all?
And there should be no distinction between $this->_price = $value; and
$this->params_array[_price] = $value; It is exactly the same variable?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Morning,

This wouldn't affect the performance of untyped properties at all.

There are extra instructions in that code.

When the code you have is only 5 instructions, adding 1 more instruction
makes a 20% increase in instructions ...

That is what we are looking at in these micro benchmarks; The number of
instructions is so small, that even the small difference is measurable.

Of course you can measure the difference, and obviously there are going to
be more instructions, but we should only care about what effects real world
code.

This doesn't effect real world code.

Cheers
Joe

Pretend I know (basically) nothing about how PHP was implemented, because
I don't ;-)

But I don't understand why regular property updates should be affected by
this at all?

If I had to implement type-checked properties in plain PHP, I would do
something like this...

/**

• @property int $price
  */
  class Product
  {
  private $_price;

  public function __set($name, $value) {
  if ($name === "price") {
  if (!is_int($value)) {
  throw new UnexpectedValueException("...");
  }
  $this->_price = $price;
  return;
  }
  throw new RuntimeException("undefined property {$name}");
  }

  public function _get($name) {
  return $this->{"{$name}"};
  }
  }

I would have guessed an implementation of type-checked properties would
work in much the same way.

Of course, it wouldn't use "_" as a prefix for the underlying property,
but some other magic byte, much like how private properties are internally
prefixed with a magic byte, right?

This wouldn't affect the performance of untyped properties at all.

Of course typed property writes would be more expensive, but that's to be
expected.

Hi Dmitry,

I hardly worked on implementation of this patch for a week, but I still
don't like it.

It makes 15% slowdown on each property update in existing PHP code
(without types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the
latest version of the patch).

-1.

If we are concerned about performance, DbC would be the only solution
for this kind of problem. i.e. Validate fully during development, do
minimum validation on production. DbC helps type inference also. There
may not be enough time for discussion, but do you think there is
enough time for implementation? I suppose implementation is
straightforward, so it might be OK to have RFC w/o implementation. We
have 2 options anyway. It's waste of time for having 2
implementations. Would you like to proceed the RFC for 7.1?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Top-posting, since I'm taking off now.

From outside the class, properties are not visible at all, so their types
are un-important from outer scopes.

echo $foo->bar; is not the same in instance method body or outside of the
class.

From outside it works just fine and doesn't throw:
https://3v4l.org/L8CqF/rfc#rfc-typed_properties

if you've hired developers that care more about trends than your
application then you've hired the wrong developers.

A consistent, complete type-system is not a "trend".

In my experience, good developers notice things like inconsistency - and
they generally do not like it.

I am personally not about trends, and don't tend to count developers who
buy into hype as "good" developers - those would not be the developers
I'd be concerned about walking. We can hire developers like those again
easily.

If every language is the same then what's the point of different
languages?

I'm not arguing "PHP should be more like X", I'm arguing for consistency
and completeness - an irrational fear of having certain similarities with
other languages really does not work as an argument against that.

Anyways, glad to hear Bob Weinland has been working on typed references and
the RFC is not dead :-)

On Sat, Nov 19, 2016 at 3:49 PM, Daniel Morris daniel@honestempire.com
wrote:

If every language is the same then what's the point of different
languages? People use Scala and PHP for different things, if your
developers are considering walking for that reason then they should
evaluate whether they want to build things or whether they want to be
trendy. Good (heck, great) developers will put to best use the tools
they have available. Migrate to Go, and watch every one of them
eventually complain about how they're having to check for err against
every function call since functions return multiple values, have them
migrate to Scala and watch their frustration as the time to change
visibility is dropped significantly; if you've hired developers that
care more about trends than your application then you've hired the wrong
developers.

--
Daniel Morris
daniel@honestempire.com

Thanks for your work on this Bob, it is very appreciated!

Hey there,

I’ve actually been working on an implementation covering also typed references, so that it’s possible to create references to a typed property, which had been a major concern back then.

See also: https://github.com/bwoebi/php-src/compare/typed_properties...bwoebi:typed_ref_properties

I’m planning to revive the RFC soon.

Bob

Am 19.11.2016 um 15:04 schrieb Rasmus Schultz rasmus@mindplay.dk:

Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
have type-hints now - it worked for return-types, but what am I doing
wrong, I can't seem to get this to work for properties?"

He actually had something like "public int $id" in a class-declaration on
his screen, and was genuinely confused - he simply assumed that would work,
since it worked for return-types. When I explained to him that, no, PHP 7
still isn't type-hinted, it's more type-hinted, but still not fully
type-hinted, he gave me the lemon-face. You know the one. Like you just ate
a lemon. Yeah.

I don't think there's a developer on my team and this point who isn't at
least checking out other languages in frustration with the lack of features
and consistency. I'm starting to feel like we're at risk of some of our
best, young developers walking, if somebody offers them a chance to work
with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying
to say that proper type-hinting is the whole answer, but I believe it would
go a long way towards consistency and the sense of completeness you get
from some of the competing languages, where these features were engineered
into the language from the design stage, rather than being added on a bit
at a time.

Any plans to revive this RFC or is it officially dead?

On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP <
mailing@pascal-martin.fr> wrote:

Le 10/06/2016 12:38, Joe Watkins a écrit :

The vote for typed properties has been restarted.

Hi,

We, at AFUP, often tend to be on the "more static / strict types" side of
things, and it remains this way for this RFC -- which means we would be +1
for typed properties.

A few noted this was not quite "the PHP way", while the majority felt this
was in line with previous changes (like scalar type declarations, nullable
types...) and could prove interesting for complex applications.

Judging from where the votes are right now, I'm guessing this RFC will not
pass, but, in any case, thanks for your work on this!

There are more "yes" than "no", so maybe it will open a path towards
something, maybe a bit different, in another future version...

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

Hi!

Any plans to revive this RFC or is it officially dead?
I really wish people won't use [Vote] subject in topics having nothing
to do with RFC voting start/stop.

It's because it's a reply to an old thread. Which is annoying in itself
for those of us using mail clients (e.g. Thunderbird) which thread by
ID, not subject line, as it bumps the entire old thread into view, like
a forum. Better to just start a blank message and quote or link the old
thread, IMHO.

Regards,

--
Rowan Collins
[IMSoP]