Hi,
I may don't have voting privileges but as an 10yr PHP development
practitioner I can't believe that such big and awesome feature like Typed
Properties minimally can't have enought votes to be a part of PHP language
(26/(26+16) = 62% and that's not enoght to 2/3+1vote).
There are plenty of places where type hinting actually exists and looks
like Typed Properties can be great complement of type system in PHP
language with the ability to still be so dynamic language as it is right
now.
The impact of 0.1% (or even more) of performance IMHO should not have no
significant meaning.
Someone earlier wrote that properties types should be ensured by frameworks
- but that doesn't never happen, the impact on performance while
dynamically type checking inside setters would be few times greates than
this patch impact. Not to mention the fact that the feature itself suggests
good practice.
Without it, we will still have setters/getters hell, and there will newer
be safe frameworks instad there will always be some hack's inside
subclasses or some other ways.
Without it, PHP will newer be aqualed such as Java, C# even Hack language -
there still will continue to be a big gap, due to the lack of type hinting.
Sure you could say start to code in Hack it has type safier system, it has
generics, annotations and other features which from time to time are in PHP
RFC's but most of time they are declined and Hack lacks of great IDE
support like PHPStorm which I use and love because of refactor, code
styling, run&debug etc.
PHP language has poor type safety and IMHO without such patches it will
never evolve into type safety programming language.
Regards,
--
Michał Brzuchalski
2016-06-13 11:40 GMT+02:00 Joe Watkins <pthre...@pthreads.org>:
> 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
>
> On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz <ras...@mindplay.dk>
> wrote:
>
> > 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.
> >
> >
> > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki <yohg...@ohgaki.net>
> wrote:
> >
> >> Hi Dmitry,
> >>
> >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> >> > 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
> >> yohg...@ohgaki.net
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
>
--
pozdrawiam
--
Michał Brzuchalski
