[chuck-users] Bad return signature in pre-constructor leads to null instance

[mike clemow]

> I agree, but it's not clear what proper behaviour should be either.

FWIW, Java complains, however, C++ silently returns 0.0--or at least
prints a 0.0.  I think that it matters less which solution ChucK uses
than the idea that it's clear about it.  i.e. ChucK should complain,
or avoid the error, but definitely not return a null object reference.

my $0.02

.mc

On Thu, Mar 12, 2009 at 9:54 AM, Kassen <signal.automatique at gmail.com> wrote:
> Robert;
>
>>
>> Did you spot the difference?  "bad_pre_constructor" is declared
>> (improperly) to return a float, but it doesn't, and an instantiation of Foo
>> silently returns a null.  "good_pre_constructor" is properly declared with a
>> void return, and an instantiation of Foo returns a good value.
>
> Ah, yes. I think this has been under debate before; functions that claim
> they will return something must return this and ChucK doesn't verify that it
> does. I think it was debated in some depth on the forum. Part of the problem
> is that it's not clear ChucK could know a function will always return when
> we do know this. Consider this;
>
> fun int invert (int input)
>   {
>   if (input == 0) return true;
>   else if (input == 1) return false;
>   }
>
> We may know that this function will only get fed a 1 or a 0 and so it may be
> "safe" but if it would get a 3 then there will be a issue. While this may be
> ok in certain contexts I'd always re-write it like this;
>
> fun int invert (int input)
>   {
>   if (input == 0) return true;
>   else return false;
>   }
>
> What we could do is require a function of a non-void type to have a "return"
> statement somewhere in it, maybe even require that it should be on the last
> line and outside of any conditions and issue a complaint otherwise, but that
> will outlaw some types of functions that may be perfectly fine. I'm a bit
> scared that rules that will prevent improper functions from being written at
> all will also stifle creativity; in many cases us programmers are a lot more
> clever than parsers are. That said; I think it's good form to always end
> functions of a non-void type with a return statement, even if it's just
> "else return false", often I will make it print a warning if it fails in
> such a way due to unexpected input.
>
> Some people insist on only having a single return statement on the last
> line. While that's very safe I feel it can lead to overly complicated
> constructs that I don't find as pleasant to read or write and that proper
> indentation and syntax highlighting can make it clear other strategies are
> safe as well; the second example I gave above does that and I consider that
> one quite natural and readable as well as clearly safe.
>
> The only reason I can think of -right now- to not have a return statement on
> the last line and outside of any conditions is when we would want to kill
> the whole shred on that line. While strictly speaking this is valid and
> might be useful that's far from clean and will likely lead to readability
> issues but is that really a reason to ban such tricks? I mean; maybe our
> foot is rebelling against us, we may have a valid reason for shooting it
> ;¬).
>
>
>>
>> This is not friendly behavior.
>
> I agree, but it's not clear what proper behaviour should be either. For now
> I'm inclined to have compilation halt if the "return" keyword isn't used in
> a function that is of a non-void type and leave the programmer to make sure
> it will return in each and every case. That would at least catch simple
> typos in the definition of the function type and give a fair warning.
>
>>
>> P.S.: Uh, is this the right forum for reporting bugs like this?
>
> Absolutely. It's interesting that you found that this issue (which in itself
> was known) will prevent object instantiation as well. I agree with you that
> the current behaviour can lead to lengthy searches due to only making a
> single typo.
>
> Yours,
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
http://michaelclemow.com
http://semiotech.org