Re: [Vala] non-null broken in vala 0.9.3



Sam Wilson píše v Pá 16. 07. 2010 v 12:42 +0000:
Jiří Zárevúcky <zarevucky jiri    > writes:


tecywiz121 píše v Čt 15. 07. 2010 v 23:06 -0400:

Bringing static code analysis would be amazing, but I have a feeling
that detecting when a variable is considered safe is an undecidable
problem (http://en.wikipedia.org/wiki/Undecidable_problem ).  Not sure
though.


I wouldn't go into discussion about whether it's decidable or not. The
fact is that a much simpler variant of that problem (whether or not
there is an if statement or assertion whose condition ensures safety) is
entirely sufficient for vast majority of cases.

If what you mean would look like this:

Foo? a = bar();
// a is unsafe and can't be accessed
if (null != a)
{
// a is safe to use in this block
}

then I don't really see how that is any different than what we have now:

Foo? a = bar();
// a is unsafe and can't be accessed
if (null != a)
{
Foo b = (!)a;
// b is now safe to use
}


The difference is in the fact you actually need to create yet another
variable and use the ugly (!) operator, which by it's nature is unsafe
and depends on programmer's skills. I'd rather implement simple
condition checking and remove the operator.

For the rest of them,
you'll just have one extra assert(), which is not a problem but rather a
good practice. 

Isn't the point of having non-nullable types to eliminate runtime checks?  When
testing your program, its very easy to miss cases that would lead to the
assertion failing, which is still a bug.


No, that isn't the point. "if (null != a)" you are using now is still a
runtime check! The point of non-nullable types is to enforce runtime
checks to properly treat null value where it's appropriate.

Yes, programmer may miss the case that leads to assertion failing. How
easy that is, however, depends on the code being written. But if the
programmer *thinks* that the condition can't fail, then he often simply
*omits* the check and dereferences it. That's why we have so many
segfaults instead of failed assertions. That means much more time spent
figuring out what actually failed. (!) operator is just another gun with
which programmer can shoot himself in the foot if used improperly. And
believe me, they WILL use it improperly. There is no mechanism that
would allow to inspect every possible state of your program and tell
you, whether or not there can be null. The most sane approach is to
actually require people to check it.

Thanks for reading,
Sam


Thanks for posting. Hope I enlightened my point of view to you. :)


Attachment: signature.asc
Description: Toto je digitálně podepsaná část zprávy



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]