...It could also be taken as a subtle suggestion to write unit tests, in which case you would discover such logical bugs within one red/green/refactor iteration. ;-)
// Carl On Sat, Jan 10, 2015 at 10:12 PM, Gabor Szabo <ga...@szabgab.com> wrote: > > > On Sat, Jan 10, 2015 at 11:02 PM, Moritz Lenz <mor...@faui2k3.org> wrote: >> >> To elaborate a bit on the previous answer: >> >> On 10.01.2015 17:12, Tobias Leich wrote: >>> >>> In case we would know that certain methods had no side effects (and are >>> not called because of their side effects), ... >>> >>> But at the moment we don't know and therefore we can't warn for every >>> method. >> >> >> there are two possible choices for warnings: run time and compile time. >> >> Run-time warnings suffer from run-time overhead, and I think this would be >> unacceptable here. >> >> Compile-time warnings can't work here, because at compile time we don't >> know what method we'll dispatch to eventually. Note that subroutine calls >> already have such warnings (in some cases): >> >> $ perl6-m -e 'sqrt(4); say "done"' >> WARNINGS: >> Useless use of "sqrt(4)" in expression "sqrt(4)" in sink context (line 1) >> done >> > > Oh right. Multiple dispatch. I see. > > anyway, IMHO the run-time overhead would be probably ok if it was optional. > Like a development mode. > It would certainly be faster than people, especially beginners like me, > wasting their time not understanding > why the method does not have an impact on that object. > > Gabor > >
