realbasic-betas.mbox
[Top] [All Lists]

Re: Ability to have more then one Return Value

To: REALbasic Betas <realbasic-betas at lists dot realsoftware dot com>
Subject: Re: Ability to have more then one Return Value
From: Nathan Fisher <virtual1 at pitnet dot net>
Date: Tue, 30 Jul 2002 01:51:23 -0500

On Monday, July 29, 2002, at 07:55 AM, REALbasic Developer Releases wrote:

Subject: Re: Ability to have more then one Return Value
From: "Geoff Canyon" <gcanyon at inspiredlogic dot com>
Date: Sun, 28 Jul 2002 08:34:49 -0700

At 12:18 PM -0500 7/27/02, Nathan Fisher wrote:
On a somewhat similar note, it would be nice for functions to be able to return more than one value. This would require a bit of a change to the compiler's syntax, but would eliminate the need for "wrapper classes" in a lot of instances.

For example, right now I might call GetAddressAndPort(Server) to get the server's address and port. As it is now, I would probably have to return it as a single string, like "192.168.1.15:110" and nthfield out the results. This would be so much handier:

    Sub GetAddressAndPort(Server as string) as string,integer
or
    Sub GetAddressAndPort(Server as string) as string, as integer

and call it like

    Address, Port=GetAddressAndPort(Server)

Does something like this have a prayer of being implemented? As far as I can tell, it doesn't break existing syntax.

Wouldn't it be fairly simple (and not require any modification to RB) to instead implement something like:

     Sub GetAddressAndPort(Server as string) as string

I should have been more specific in my post... I'm not looking for work-arounds, I was discussing a possible feature request. There are many instances where I would like a function to pass back multiple (typically 2 or 3) results, but using wrapper classes or delimited strings is inconvenient and obscures the meaning of the code. In many instances, it requires a wrapper class that will only be used for that one method or new event, and nowhere else in the project.

I believe my method is clearer than using wrapper functions, and much clearer and more flexible than delimited strings. Calling ByRef is something I prefer to avoid, because you are basically engineering a "side-effect" on purpose, and all my schooling says side-effects are -bad-. (anyone else familiar with Forth and its side-effect compiler bug that lets you redefine the value of integer literals?) This is why I am offering discussion for a better option. Multiple LValues appear to me as visually clear and efficient, and don't conflict with existing syntax, which is why I suggest it

- Nathan



<Prev in Thread] Current Thread [Next in Thread>