On 23/8/06 17:35, "Mars Saxman" <[EMAIL PROTECTED]> wrote:
> Well, that's where the second half of that sentence applies: it is
> not clear to me that the change would be a benefit.
It is very clear to me. It would make much of my code clearer :)
Surely if one is of the OO persuasion and is "sold" on the benefits of
polymorphism, then overloading based on return type is essentially the same
sort of "thing" as doing it on arguments.
> Overloading is hard to use precisely when it causes ambiguity, and obscures
rather
> than clarifying programmer intent.
Not sure what that means exactly -but in any case surely isnt it for US
users to decide when such use would cause ambiguity?
There are lots of language features which if used unwisely might lead to
confusion - for example operator overloading - which for those very reasons,
Sun omitted from Java based on your type of arguments, but it is to RS's
credit that they DID include operator overloading. And used wisely it is a
great boon.
> Overloading based on return types would multiply this ambiguity, at great
cost,
To whom ? The RS guy tasked with the challenge of changing RB to support
this new feature? Or to us?
Surely it isnt our cost - after all we can always avoid using return type
overloading in those situations ambiguity might arise - for example where
variants are involved.
I basically avoid variants wherever possible so it wouldn't be a problem.
Give us the feature and let us decide when and where its wise to use it.
> for what seems to me a relatively minor improvement in API-design flexibility.
to you maybe- not to me. RS has made lots of "minor" improvements to the
core language over the years and I have appreciated and used most of them.
If one believes in the precepts of good OO practice it seems to me that
applying polymorphism to return types is both logical and reasonable.
_______________________________________________
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>
