AS3 overloading?

Is it possible to overload methods in AS3? I.e. would this work?

public function pixelAt(index:uint):uint
{
	
}
public function pixelAt(x:uint, y:uint):uint
{
	
}

That would be extremely useful…

Nope, all you have is default arguments.

You could build it by yourself:

public function pixelAt(indexorx:uint, possiblyy:uint = null):uint
{
    var result:uint;
    (possiblyy == null) ? result = pixelAtIndex(indexorx) : result = pixelAtCoords(indexorx, possiblyy);
    return result;
}

private function pixelAtIndex(index:uint):uint
{

}

private function pixelAtCoords(x:uint, y:uint):uint
{
    var index:uint = y * whateverBitmapYoureUsing.width + x;
    return pixelAtIndex(index);
}

Guaranteed to use slower ternary operations and waaay more incredibly slow function calls than is absolutely necessary, but there’s no duplication and I’ll be damned if you have to read this code twice to figure out what it does. :p

Any difference between this

(possiblyy == null) ? result = pixelAtIndex(indexorx) : result = pixelAtCoords(indexorx, possiblyy);

and this

result = (possiblyy == null) ? pixelAtIndex(indexorx) : pixelAtCoords(indexorx, possiblyy);

or

result = possiblyy ? pixelAtCoords(indexorx, possiblyy) : pixelAtIndex(indexorx);

or

return (possiblyy == null) ? pixelAtIndex(indexorx) : pixelAtCoords(indexorx, possiblyy);

directly. Sure, why not. Note that (possiblyy) evaluates to false if y is null or 0 however. In this case it makes no difference, but it might in general, so I kept the (possiblyy == null), for clarity. Also, I always keep the condition between parentheses when writing ternaries, even if it’s not necessary, because it makes the line more readable. It guides the eye to the boundaries of the condition, leading to the question mark. I know the compiler won’t care, but I do, so I put them.

But isn’t calling functions making it slower?

Yea. You can just check for y in in original constructor itself. It will only require an if statement :)

Originally posted by Ace_Blue:

or

return (possiblyy == null) ? pixelAtIndex(indexorx) : pixelAtCoords(indexorx, possiblyy);

directly. Sure, why not. Note that (possiblyy) evaluates to false if y is null or 0 however. In this case it makes no difference, but it might in general, so I kept the (possiblyy == null), for clarity. Also, I always keep the condition between parentheses when writing ternaries, even if it’s not necessary, because it makes the line more readable. It guides the eye to the boundaries of the condition, leading to the question mark. I know the compiler won’t care, but I do, so I put them.

uint can’t hold the value null. it will be coerced to 0 unless the compiler yells at you for using incompatible types that way.
you’d have to use either Number (so you get the special value NaN to toy with) or :* (so you get null/undefined)

Just from what Bob said up there ^

function pixelAt(...args)
{
	if (args.length==1) {
		trace("single index call", args[0]);
	} else if (args.length==2) {
		trace("coordinate call", args[0], args[1]);
	} else {
		trace("unexpected call", args);
	}
}
pixelAt();
pixelAt(1);
pixelAt(1,5);

I have no idea how efficient it is… but it seems to fit the bill

Originally posted by skyboy:uint can’t hold the value null.

Interesting, I didn’t know that. But now that you mention it, it does make sense. Anyway, after thinking about it some more, I’m more worried about pixelAt() being confusing when it’s used one abstraction level up: One time it would take one argument, another time two. That’s bound to confuse the reader who will then have to go look up the function definition and unravel the logic. In the end I think I would just do away with pixelAt(), and make both pixelAtIndex and pixelAtCoords public (if they need to be called from outside the class only, of course). That is, if having both functions is actually critical. Readability and consistency might be improved by standardizing the way pixels are fetched in the first place.

I usually just checks the code hint if I’m in doubt.

Since I doubt you’ll be working with images that have a height of around 4294967295 pixels:

public function pixelAt(indeX:uint, y:uint = uint.MAX_VALUE):uint
{
	if (y == uint.MAX_VALUE)
	{
		//use indeX as an index to get coords
		//overwrite indeX and y with the results
	}

	//use indeX and y as coords
}

Or inverse it if you want to go from coords to index. Just make sure you document the function well if you don’t want it to haunt you back in six month.

@Solanix yeah that’s a possible way

Originally posted by skyboy:

uint can’t hold the value null. it will be coerced to 0 unless the compiler yells at you for using incompatible types that way.
you’d have to use either Number (so you get the special value NaN to toy with) or :* (so you get null/undefined)

So that mean’s you can just write var a:uint; instead of var a:uint = 0;?

Originally posted by ErlendHL:

So that mean’s you can just write var a:uint; instead of var a:uint = 0;?

No. In fact you should probably never name a variable ‘a’. Even if the variable represent something that starts with ‘a’ and usually uses the symbol ‘a’ in Math or Physics equations, you should not name it ‘a’. You should name it for what it represents, ‘acceleration’, for instance. Long gone are the days when variable names were limited to 8 characters. Make your code explicit.

As for the distinction between uint; and uint = 0; no, they do not say the same thing. a:uint; says: “I’m declaring a variable and I will be using it later on. It will be assigned a value at the appropriate time.” a:uint = 0; says: “I’m declaring a variable and I need its value to be 0, now.” Furthermore, if ‘a’ happens to be a class variable, it also says: “This variable is actually more of a constant, or at least a parameter, and I’m declaring its value up here once and for all, so I’ll know to alter it here if I ever want to give it a different value in another build.” or “This variable is being given a value here because I have no effing clue how to properly initialize a class and I’m trying to patch a runtime error of accessing a property of the class which doesn’t have a value at the time it’s called on.” This last one wouldn’t happen with uints, apparently, but you get the gist.

Originally posted by Ace_Blue:

Originally posted by ErlendHL:

So that mean’s you can just write var a:uint; instead of var a:uint = 0;?

No. In fact you should probably never name a variable ‘a’. Even if the variable represent something that starts with ‘a’ and usually uses the symbol ‘a’ in Math or Physics equations, you should not name it ‘a’. You should name it for what it represents, ‘acceleration’, for instance. Long gone are the days when variable names were limited to 8 characters. Make your code explicit.

As for the distinction between uint; and uint = 0; no, they do not say the same thing. a:uint; says: “I’m declaring a variable and I will be using it later on. It will be assigned a value at the appropriate time.” a:uint = 0; says: “I’m declaring a variable and I need its value to be 0, now.” Furthermore, if ‘a’ happens to be a class variable, it also says: “This variable is actually more of a constant, or at least a parameter, and I’m declaring its value up here once and for all, so I’ll know to alter it here if I ever want to give it a different value in another build.” or “This variable is being given a value here because I have no effing clue how to properly initialize a class and I’m trying to patch a runtime error of accessing a property of the class which doesn’t have a value at the time it’s called on.” This last one wouldn’t happen with uints, apparently, but you get the gist.

Well, I disagree with pretty well all of that :P

Originally posted by Ace_Blue:

As for the distinction between uint; and uint = 0; no, they do not say the same thing. a:uint; says: “I’m declaring a variable and I will be using it later on. It will be assigned a value at the appropriate time.” a:uint = 0; says: “I’m declaring a variable and I need its value to be 0, now.” Furthermore, if ‘a’ happens to be a class variable, it also says: “This variable is actually more of a constant, or at least a parameter, and I’m declaring its value up here once and for all, so I’ll know to alter it here if I ever want to give it a different value in another build.” or “This variable is being given a value here because I have no effing clue how to properly initialize a class and I’m trying to patch a runtime error of accessing a property of the class which doesn’t have a value at the time it’s called on.” This last one wouldn’t happen with uints, apparently, but you get the gist.

MXMLC automatically initializes all variables that are not explicitly initialized at the start of the function; before anything else executes. any class property that is not explicitly defined gets the class’s default value (null, undefined, 0, NaN, false, etc.).

there is never a time when a variable will not map to a location in memory that holds a value. even if that value is null, undefined, or some other alternative.

I’m not talking about what it says to the computer. I’m talking about what it says to the reader.

I’m the only reader so it’s okay for me. Also a was just an example.

Using the … syntax loses you a lot of compile time sanity checking: you no longer get a compile error for passing the wrong number or the wrong type of parameter. That’s not a price worth paying to get overloading.

Originally posted by BobJanova:

Using the … syntax loses you a lot of compile time sanity checking: you no longer get a compile error for passing the wrong number or the wrong type of parameter. That’s not a price worth paying to get overloading.

You can throw your own run-time errors though. Sometimes overloading can be a very important part of your program.