incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: AS3 Enhancements: method overloading. Why do people want this?
Date Tue, 17 Jan 2012 06:43:11 GMT
On 17/01/2012 07:03, Iwo Banaś wrote:
> ...and it will definitely not
> solve the naming conflicts of no-arguments methods (like the
> destroyed() getter).

A methods signature does include the return-type.

var a:String = some.myprop; // uses function get myprop():String;
var b:int = some.myprop; // uses function get myprop():int;

So: it will solve that problem too.

On 17/01/2012 07:03, Iwo Banaś wrote:
>   ...trying to do too much.

It might be the case that code is trying to do too much, but it might be 
also the
only option left for a straight forward solution. There are plenty of 
possibilities for
code-use out there, basically all language structures have a good and a 
bad side...
I'd say lets focus on the good ones, at least until we find a show stopper.

On 17/01/2012 07:11, Iwo Banaś wrote:
> I doubt if it's worth implementing (hack together) the controversial
> feature just for very specific usecases.
I would categorize it as difficult but not controversial. Its hard to 
add language structures, any language structure for that matter, and I 
toll high respect to AS3 and its creators because of many of is features.

It is better to be able to experiment with a new feature than trying to 
talk about it. So: even if categorized as hacky (which I am not sure it 
is) I think it is worth trying.

On 17/01/2012 09:50, Rick Winscot wrote:
> which means that the real question should be, "would the
> performance gains of overloading in ActionScript be on-par with the
> gains realized in a compiled language like C, or C++?"
I don't see a reason why it shouldn't be on-par for strict cases. 
Backward compatible code or non-strict code might need additional 
implementations but all that can just be found out while trying to 
implement it.

On 17/01/2012 09:59, Doug McCune wrote:
> Unless a goal is to target a language, like JavaScript, which also doesn't
> have method overloading...
It can be implemented using string prefixes or if/else switches and 
alike even without multimethods available. It wouldn't be the first 
feature that needed to be mangled into the JS language as JS doesn't 
support many constructs.

Another thought: all that overloading could be syntactically done using 
other means:

function mymethod {
(str: String):String { }
(a:int):int {}
}

Which might be easier to document.

All that overloading aside: Today i often see code like

function save(obj:*) {
if( obj is String ) {
} else if( obj is int ) {
} else {
throw ...;
}
}

Which is not just stressful to write but also "error prone". Having 
syntactic sugar for this case might be nice. I could think of something 
like this:
function save(obj) {
checkType(obj) {
String: saveString(obj); // "obj" is automatically cast as string
int: saveInt(obj); // "obj" is automatically cast as int
// throws error message if not of one of these types
}
}

Its less to write than the if switches, the types are already cast and 
generally one source less for errors.

yours
Martin.

Mime
View raw message