Lots of functions! How should I seperate them?

[Baby Minion]

Hey FK!

Hoping I could get a little personal preference input here.

I have written a library. This library has a function that has an argument being a function.

//(its static)
class MyClass {
    function foo(method:Function):void;
}

I have created over 30 functions that are acceptable as an argument to that function. But they raise the file size by 6kb alone! So I've found that most people won't use more than an average 6 functions in a program, so why use all that extra space?

I am trying to find a way to have all of these functions available in their own 'namespace' so that compiler only puts in the functions that are referenced specifically. I also want a way that I can still force all of them to be compiled in (like a manifest).

Below, is how these functions are currently setup:

class MyClass {
    function foo (method:Function):Array;
}
class Methods {
    function bar1 (param1, param2):void;
    function bar2 (param1, param2):void;
    function bar3 (param1, param2):void;
    function bar4 (param1, param2):void;
    etc...
}

I really just want personal preference input here
If you were using a library that was built this way, how would you want to interact with these interchangeable functions?
Below are three ideas I have already thought of. Please, at least just reply with which one you like the best.



Options:

Package Level Functions:
Make them all package level functions. You would import one at a time.

package com.net.methods {
    function bar1 (param1, param2):void;
}
package com.net.methods  {
    function bar2 (param1, param2):void;
}

package {

    import com.net.methods.bar1;
    import com.net.methods.bar2;

    class Main {
        function doSomething ():void {
            MyClass.foo(bar1);
            MyClass.foo(bar2);
        }
    }
}

To cover the manifest problem, I could create a class that imports all of the functions, then all you have to do is reference that class in any class.

package {
    import com.net.methods.bar1
    import com.net.methods.bar2
    import com.net.methods.bar3
    import com.net.methods.bar4
    //etc...
    class MethodManifest {
        bar1;
        bar2;
        bar3;
        bar4;

        function MethodManifest() {

        }
    }
}

package {
    import MethodManifest;
    class Main {
        MethodManifest;
        function Main() {
            
        }
    }
}

Grouped by Functionality
Another idea is to group the function by commonality.

class Xbased {
    function bar1 (param1, param2):void;
    function bar2 (param1, param2):void;
    function bar3 (param1, param2):void;
}
class Ybased {
    function bar4 (param1, param2):void;
    function bar5 (param1, param2):void;
    function bar6 (param1, param2):void;
}
package {
    import Xbased;
    class Main {
        function Main () {
            MyClass.foo(Xbased.bar1);
        }
    }
}

One Class, One Function
Lastly, I guess you could make a separate class for each function. Maybe this would give me greater flexibility in the end but that is unclear.

class bar1 {
    function execute (param1, param2):void;
}
class bar2 {
    function execute (param1, param2):void;
}
class bar3 {
    function execute (param1, param2):void;
}

package {
    import com.net.methods.bar1;
    class Main {
        function Main () {
            MyClass.foo (bar1.execute);
        }
    }
}

What do you think? How would you structure this? Thanks for any and all input!

[jAQUAN]

TweenMax has a pretty good plugin architecture. I'd look at TweenPlugin.activate() to see a good example.

[Baby Minion]

I took a look at TweenMax. There is a lot to follow (in my opinion) but I think I get the gist of it.

It does appear that what I am doing is similar to a plugin concept, but I'm not sure this library needs that level of complexity. If I made a plugin, it would only have one function inside of it. There is nothing more complex than that.

While I'm not ready to divulge the entirety of my library yet, I wonder how much other input I'll get.

But since you've mentioned 'plugins' does anyone have any other references to plugin architectures (preferebly done in AS# and SIMPLE ones)

[5TonsOfFlax]

In terms of api clarity, I'd then each to be a method of a single larger class. But it sound like minimal compile size is one if your goals. package level functions are a good alternative.
I also like one class per function because you can have those classes implement an interface and improve your static type checking. but I don't know how much overhead that would incur.

[Baby Minion]

Thanks for the response!

I forgot about the added benefit of the one method per class using an interface.
I'm not sure it would add much overhead, and I could get each to extend a base class that has other super common static utility functions.

I am going to test this out and see how it affects the workflow and filesize. Thanks

[Baby Minion]

I ended up creating a base class with an abstract function definition. The concept worked great. However it did increase filesize. *edit* Think I'll try just an interface and see how that goes */edit*

The reason why I'm concerned about filesize is that this library will primarily be used in an environment where bandwidth is scarce, so the smaller I can make my libraries the better.

So, even though this solution increases filesize, I think it is still acceptable. The reason? because the use case that any one application would use more than a few of these 'plugins' is so small, that the average application would compile fewer bytes than my previous method of including all every time. Also, I have a bunch of optimizing to do which will decrease filesize.

Thanks for the input guys. I'm still open to other ideas though.