Hi (all), On Mon, Dec 28, 2015 at 6:23 PM, Elijah Johnson <ejrx7...@gmail.com> wrote:
> Hi (all), > > On Mon, Dec 28, 2015 at 3:40 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> Hi all, >> >> On Tue, Dec 29, 2015 at 5:28 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> > Object(class) is type, so it makes sense checking class consistency. If >> we >> > check object's class, not only the class but also ancestor classes >> should be >> > checked. This may affect performance. >> > I'm not sure if this worth the effort. >> >> It sounds negative, so I correct this. >> >> Since we have class type hint, it better to support class check. IMO. >> Almost all cases are simple class equality check. So it wouldn't hurt >> performance much, I suppose. >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> > > I think that it would be worthwhile to get either a RFC or some test code > on this, the latter depending on how you would assess the difficulty. The > feature itself has a huge demand and goes along the lines of current > development. > > If something could be developed, then we could assess performance. I would > estimate it to be small, however in any case the feature is optional. We're > not anymore considering to increase the size of the z-val. > > The feature has 2 stages, one of which would be drastically easier to > implement and would show us about performance. > > Stage 1 - typing only objects already set by comparing classes upon > assignment, if set a particular mode > > Stage 2 - Adding some form of language hint, which will require a parser > and some method of storing the class hint for null objects. The latter has > a proposed solution not sounding hard to implement, but modifying the > parser sound like a more difficult step. > I'm changing the name of this thread. I'm not sure why the original mailer labeled it "Make strict mode more strict?". This has been a discussion about extending type hinting to stack variables and resulted in a possible/plausible solution that we are looking to evaluate.
