On Mar 23, 2007, at 9:38 PM, Chris Little wrote: > The problem with this is that you can't tell what each return value > is. To > use an example from another of your replies: > > Function ParseDate(stringDate as string) as integer, integer, integer > > How do you tell the order of the return values? The function > signature loses > all self documenting ability. You would at least have to have some > kind of > naming of return values.
This is no more nor less confusing than having to remember what the order of the arguments is when calling a method. >> If the number of lvalues differs from the number of return values, >> then: >> >> - if there are more lvalues, the excess values are Nil/0/""/etc >> - if there are excess return values, the excess are ignored. >> >> Notice that these semantics lets the function return values in the >> order that is most useful. CountWords then doubles as a handy "unique >> words" function: > > I don't like this at all. It could lead to fragile code once when > you start > having to account for type conversions. Please explain. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
