> I respect your right to disagree, and your point is valid, but I feel > a need to pick one nit -- failing to return true may always be an > error in YOUR code, but it's generally not in my code. I sometimes > omit the return statement intentionally; since it's done > intentionally, based on the documented behavior of the language, and > has the effect I want, it is not an error.
Ah come on now. This behavior is not documented anywhere I can see. The language reference for a function is silent on the fact that the return type is not required. The fact that Rb simply *allows* this does make your code any more correct or *document* it. A function, by definition, returns a value. Period. Rb added a Call() statement to allow users not to have to use the value sometimes. Rb is a strongly typed language and it stays to this tenet its design (as you know a heckofa lot better than I!). I consider this discussion of behavior to be in the light of this. If you're against Rb telling us that your declared function, that is in masquerade as some pseudo-subroutine-function, is not returning a value, then fine. And if you do not want this feature to be added because it breaks some of your code, then fine. But to defend it just because Rb currently allows this is where we differ on what an error is. And BTW, I'm for Rb stopping the compile on this, no ifs ands or buts. No silly preferences or other such devices to cloud up the, as is, clear waters of our beloved Rb IDE compiling process. -- Thomas C. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
