I changed my opinion and would even go one step further.
It seems to be a real performance breakdown to create 10 (in
the complex overloading methods of TestCase) handlers by
executing one assertEquals call. This would gain pretty much
if the structure of the overloading could be set at
construction time:
class MyClass {
private static var assertEqualsOverloading:Overload;
private static var overLoadAssertEquals(instance:MyClass,
args:Array) {
if (!assertEqualsOverloading) {
var o:Overload = assertEqualsOverloading = new Overload();
o.addHandler([String, Number], /** Reference to the
method in the Prototype chain - perhaps a Util would be
great */);
}
return assertEqualsOverloading.forward(instance, arguments);
}
public function assertEquals() {
return overloadAssertEquals(this, arguments);
}
}
Would at least be pretty performant ...
The second thing for overloading is that this might be a
pretty nice intelligent data holder like:
var switch:ComplexSwitch = new ComplexSwitch();
switch.addCase([Function, String], "hoho");
switch.addCase([String], "hihi"];
switch.setMatcher(new TypeInstanceMatcher());
trace(switch.getCase(["hi"])); // traces "hoho"
Overload could be a extended version that sets the correct
matcher and contains the addHandler and forward methods.
yours
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed my opinion and would even go one step further.
It seems to be a real performance breakdown to create 10 (in
the complex overloading methods of TestCase) handlers by
executing one assertEquals call. This would gain pretty much
if the structure of the overloading could be set at
construction time:
class MyClass {
private static var assertEqualsOverloading:Overload;
private static var overLoadAssertEquals(instance:MyClass,
args:Array) {
if (!assertEqualsOverloading) {
var o:Overload = assertEqualsOverloading = new Overload();
o.addHandler([String, Number], /** Reference to the
method in the Prototype chain - perhaps a Util would be
great */);
}
return assertEqualsOverloading.forward(instance, arguments);
}
public function assertEquals() {
return overloadAssertEquals(this, arguments);
}
}
Would at least be pretty performant ...
The second thing for overloading is that this might be a
pretty nice intelligent data holder like:
var switch:ComplexSwitch = new ComplexSwitch();
switch.addCase([Function, String], "hoho");
switch.addCase([String], "hihi"];
switch.setMatcher(new TypeInstanceMatcher());
trace(switch.getCase(["hi"])); // traces "hoho"
Overload could be a extended version that sets the correct
matcher and contains the addHandler and forward methods.
yours
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=901744
The Parameter in the Constructor is for the Object the
Overloading will forward to.
var o:Overload = new Overload(this);
Why would you remove it (loosing scope scares me)?
In Static methods you can use eval("th"+"is");
If you mean you want to have a Handler that takes no
parameter you can use:
o.addHandler([], myFunction);
I guess thats the only point where i could accept to take:
o.addHandler(myFunction); instead.
Logged In: YES
user_id=901744
I changed my opinion and would even go one step further.
It seems to be a real performance breakdown to create 10 (in
the complex overloading methods of TestCase) handlers by
executing one assertEquals call. This would gain pretty much
if the structure of the overloading could be set at
construction time:
class MyClass {
private static var assertEqualsOverloading:Overload;
private static var overLoadAssertEquals(instance:MyClass,
args:Array) {
if (!assertEqualsOverloading) {
var o:Overload = assertEqualsOverloading = new Overload();
o.addHandler([String, Number], /** Reference to the
method in the Prototype chain - perhaps a Util would be
great */);
}
return assertEqualsOverloading.forward(instance, arguments);
}
public function assertEquals() {
return overloadAssertEquals(this, arguments);
}
}
Would at least be pretty performant ...
The second thing for overloading is that this might be a
pretty nice intelligent data holder like:
var switch:ComplexSwitch = new ComplexSwitch();
switch.addCase([Function, String], "hoho");
switch.addCase([String], "hihi"];
switch.setMatcher(new TypeInstanceMatcher());
trace(switch.getCase(["hi"])); // traces "hoho"
Overload could be a extended version that sets the correct
matcher and contains the addHandler and forward methods.
yours
Martin
Logged In: YES
user_id=901744
I changed my opinion and would even go one step further.
It seems to be a real performance breakdown to create 10 (in
the complex overloading methods of TestCase) handlers by
executing one assertEquals call. This would gain pretty much
if the structure of the overloading could be set at
construction time:
class MyClass {
private static var assertEqualsOverloading:Overload;
private static var overLoadAssertEquals(instance:MyClass,
args:Array) {
if (!assertEqualsOverloading) {
var o:Overload = assertEqualsOverloading = new Overload();
o.addHandler([String, Number], /** Reference to the
method in the Prototype chain - perhaps a Util would be
great */);
}
return assertEqualsOverloading.forward(instance, arguments);
}
public function assertEquals() {
return overloadAssertEquals(this, arguments);
}
}
Would at least be pretty performant ...
The second thing for overloading is that this might be a
pretty nice intelligent data holder like:
var switch:ComplexSwitch = new ComplexSwitch();
switch.addCase([Function, String], "hoho");
switch.addCase([String], "hihi"];
switch.setMatcher(new TypeInstanceMatcher());
trace(switch.getCase(["hi"])); // traces "hoho"
Overload could be a extended version that sets the correct
matcher and contains the addHandler and forward methods.
yours
Martin