Hi (all),
Hi (all),
Hi all,
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
yohgaki@ohgaki.netI 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 modeStage 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.
Hi (again),
Hi (all),
On Mon, Dec 28, 2015 at 6:23 PM, Elijah Johnson ejrx7753@gmail.com
wrote:Hi (all),
Hi all,
On Tue, Dec 29, 2015 at 5:28 AM, Yasuo Ohgaki yohgaki@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
yohgaki@ohgaki.netI 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 modeStage 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.
This thread is totally ruined because some mail client automatically cut
the threads. No one can easily browse back to see what we discussed and
agreed on. We will have to reformat our idea completely.