Top-posting due to mobile conn.
I voted no due to flaws introduced in the language by the current RFC.
The performance impact is irrelevant.
On Jun 22, 2016 11:38, "Michał Brzuchalski" <mic...@brzuchalski.com> wrote:
> 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
>
