Where best to put utility functions

[QuantumTiger]

Hi

In the AS3 project I'm working on at present I can see the need for a few (small) utility functions which several classes need access to. What's the best place to declare them?

The options I've currently thought of are 1) to extend Sprite (eg to mySprite), place the utilities there and then make all the dependant classes extend mySprite or 2) to create a small utility class, create an instance in my main class and pass a reference to it to the objects which require it.

Any options I've missed? Any thoughts on which method would be most efficient? Many thanks...

[pj-co]

I've always thought of utility classes as mostly static personally. Though I guess it kind of depends on what you mean by utilities.

[yell0wdart]

Personally, I'd create static classes within their own namespace or package to house all my utility methods (TextTools, EnumHelper, XmlTools, etc). That way you're not bloating your objects with a bunch of methods that they may or may not need. No need to inheritance-crazy just to extend functionality.

[Flash Gordon]

My utilitlies are all in a folder called utils. I have

XMLUtil
ArrayUtil
StringUtil
quickCopy(DisplayObject)
etc .......

[QuantumTiger]

Thanks guys - that's very helpful.

[swivelmaster]

Please tell me what quickCopy(DisplayObject) does. There's a whole debate on Adobe's bug database about the lack of ability to do a real copy of any DisplayObject data.

In regards to the original question, static classes are where it's at.

I also have some helpers that require instances to be made, but exist completely separately. One is for calculating file sizes, and includes instance variables for bytesLoaded and bytesTotal, and at any point you can get those values back converted to any size unit (byes, k, m, g, t, and p for the far future!). The conversion functions are still static though.

[pj-co]

Originally Posted by swivelmaster

Please tell me what quickCopy(DisplayObject) does. There's a whole debate on Adobe's bug database about the lack of ability to do a real copy of any DisplayObject data.

In regards to the original question, static classes are where it's at.

I also have some helpers that require instances to be made, but exist completely separately. One is for calculating file sizes, and includes instance variables for bytesLoaded and bytesTotal, and at any point you can get those values back converted to any size unit (byes, k, m, g, t, and p for the far future!). The conversion functions are still static though.

$20 says FG has a class that grabs all the known properties of the DisplayObject and creates a new one with those properties

[pj-co]

Originally Posted by pj-co

$20 says FG has a class that grabs all the known properties of the DisplayObject and creates a new one with those properties

except that doesn't work for the graphics object

*smacks self on head *

I see what you mean swivelmaster. Interesting talk on adobe's JIRA site.

[NickZA]

Um, Is this turning into a thread on deep copying?

Always interested in what other people use, here's the most recent info I've found on that.

http://www.richapps.de/?p=34
http://www.stimuli.com.br/trane/2007...ng-or-cloning/

@pj-co,

except that doesn't work for the graphics object

could you explain?

[rawmantick]

except that doesn't work for the graphics object

*smacks self on head *

I see what you mean swivelmaster. Interesting talk on adobe's JIRA site.

Graphics can be copied separately either. Check copyFrom() method.