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.
