On Mar 23, 2007, at 4:37 PM, Guyren Howe wrote:
> On Mar 23, 2007, at 4:58 PM, Norman Palardy wrote:
>
>> That's not to say I have not found myself needing to return several
>> items from a single function and have used byref to do so
>> If you run into the need to do this on a regular basis you might re-
>> examine the "type" being returned and create a class to contain that
>> data or use a dictionary or array.
>
> <rant>
>
> There are two main reasons this is better:
>
> 1. It's clearer. Compare this:
>
> Year, Month, Day = ParseDate(someValue)
>
> With this:
>
> ParseDate(Year, Month, Day)
Why not
Date = parseDate(someValue)
> It isn't in any way obvious that the second is modifying the
> variables passed to it.
Agreed
> 2. It's quicker and easier to write, both in the function and in its
> use. Compare:
>
> Dim Year, Month, Day As Integer = ParseDate(someValue)
Or the eminently more succinct
dim someGoofyName as Date = parseDate(someValue)
> With this:
>
> Dim Year, Month, Day As Integer
> ParseDate(Year, Month, Day)
>
> Okay, it's just one line. And none of this is a huge deal. But I defy
> anyone to disagree that the multiple return form is both more concise
> and considerably clearer. How is that not something to strive for?
It's less concise only in that you get a DATE not a year. month and day
It would be just as accurate to write
Dim bananas, oranges, apples As Integer = ParseDate(someValue)
and .. yuck !
> Or this:
>
> Sub SomeFn...
>
> RetVal1 = Val1
> RetVal2 = Val2
> Return Val3
>
> End Sub
>
> With:
>
> Return Val1, Val2, Val3
>
> In this case, also, it's not clear that the former is returning the
> three values, unless you look at the call signature.
Very true.
I try to avoid byref return values because it is opaque
> And don't get me started on "just declare a class". If all I want is
> to deal with these three values, it's certainly *much* easier to just
> deal with the three values than to go to all the busywork of making a
> class, giving it a constructor so it's not too much of a pain to use,
> and all that palaver. OOP is great. I love OOP. But much of the time,
> it's overkill. One of the reasons I use REALbasic and not Java is
> that you have to use classes in Java, but in REALbasic, when OOP is
> overkill, I don't have to use OOP. I would like to have more
> facilities such as those in Perl and Python, that let me get stuff
> done without all that busywork (eg array slices, anonymous functions,
> delegates, closures).
OK so many don't want REAL C++ (recall the debate about ++ and --
operators) but REAL Perl is OK ?
> The semantics I've proposed are perfectly clear eg in the case of
> nesting function calls. And if we fixed the inability to write array
> subscripts after array-returning functions:
>
> SomeFun(someValue)(1)
>
> and stipulated that the return could also be treated a an array, then
> you'd answer questions such as "what if I only want the count".
>
> The simple fact is that we all write functions with multiple return
> values now.
No, I don't or at least I try not to.
I return a class, a dictionary or something else that is specifically
designed for the purpose intended.
> Only we use ByRef which is completely invisible in the
> call and the function and somewhat more tedious to use on both ends.
> This isn't a ground-shaking proposal, but there is absolutely no way
> in which it isn't better than ByRef.
Never said it wasn't but I remain unconvinced that it's better than
anything else we already have the capability of doing or that it
really is necessary.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
