Sam Wilson píše v Pá 16. 07. 2010 v 12:42 +0000: > Jiří Zárevúcky <zarevucky.j...@...> 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. :)
signature.asc
Description: Toto je digitálně podepsaná část zprávy
_______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
