Actually, that's not quite true in your example above. Return type covariance allows subclasses or interface implementors to implement a method specifying a more specific type as the return type. For example, if the interface defined the Item method as "Item(i as Integer) as Object", the implementation could be "Item(i as Integer) as Foo". This would satisfy the interface's contract, as Foo IsA Object.
Good point, but it won't work if Foo is not an Object. It also feels less type safe -- although I haven't actually tried it, so that might be an illusion. (I suppose one could make a "Listable" interface to reduce that feeling, but that's backwards; why should a type have to know whether it can be put in a list?) lj _______________________________________________ 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>
