On May 03, 2006, at 18:04 UTC, Jason Essington wrote: > Actually not, since the array of apples passed to a method as an > array of fruits is still an array of apples, any attempt to append a > fruit that is not an apple should simply raise an > IllegalCastException at runtime.
Well, yes, that's what could happen in a weakly-typed language, but RB is not one of those. RB does type-checking at compile time, with only a few exceptions (such as when you explicitly downcast a variable). This is generally a good thing, since (1) it's faster at runtime, and (2) it tends to catch mistakes earlier (at compile time instead of at run time). What you're describing isn't ridiculous, but it would require that all object arrays (1) keep extra information around regarding their "true" type (since that may differ from their static type)< and (2) do runtime type checking on every assignment into, or addition to, the array. > Sub badFruit(ByRef f As Fruit) > f = new Orange() > End Sub > > Dim a as new Apple() > badFruit(a) > > Rather than getting a compile exception at badFruit(a), I would > expect to get an IllegalCastException at f = new Orange(). Try it! I would expect the compiler to tell you to take a hike (or at least, that you've passed an incorrect type on the badFruit call). > > So you can see, just because an Apple IsA Fruit, does NOT mean that > > an array of Apples IsA array of Fruits. > > B-B-B-But an array of Apples IsA array of Fruits! A rather specific > array of Fruits, but still an array of Fruits. No, not in RB. It's the element type that is a more specific fruit, not the array itself. The subclass nature of the elements doesn't percolate up to the container. > Well, It isn't naivety that makes me think that it should work, it is > that it does work exactly that way in my primary language (Java). Really? I didn't know that. I'm a bit surprised; in most ways Java's semantics are just like RB's. This is a bit of type looseness I wouldn't have expected from the Java designers. > So, unfortunately, what I thought was a fairly simple problem, in > REALity ends up being a bit more complicated, but with the benefit > that it is much harder to shoot yourself in the foot. That's a good summary. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Available for custom REALbasic programming or instruction. _______________________________________________ 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>
