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.
