This content has been marked as final. Show 3 replies
> Having gone that far it would be fairly simple to convert
> this to a class but apart from being "the right thing to do",
> would there be any advantage?
This isn't always true in real life, but in programming, "the right
thing to do" is a flexible concept. In programming, "the right thing to do"
is generally whatever works best for your workflow, or the workflow of your
team. If you don't see the benefit of a certain recommended best practice,
why go to the trouble?
For example, I like Turkish coffee. The way I prepare it, the process
takes quite a while. I have to grind my beans into, essentially, flour. I
add the "flour" to a special conical pot, along with sugar, cardamom, and
anise, and heat it -- but not to boiling -- until it starts foaming. That
takes about 20 minutes. It's extra work, but I absolutely love the stuff.
Totally worth it. And it helps my workflow. ;)
In Flash, when coding on the timeline, I put (most) of my code in a
layer dedicated to solely to ActionScript. Why? Because I personally find
it easier to locate my code when it's all in one place. Most of the
developers I know find this practice equally helpful, so it's no surprise
that it's a recommended best practice.
I personally prefer the dot notation approach to event handling in AS2.
To me, the older approach -- on() and onClipEvent() -- is less powerful and
flexible. (See the link for details.)
As it turns out, avoding on() and onClipEvent() is nowadays considered a
recommended best practice. It's the "right thing to do" ... but plenty of
folks still use on() and onClipEvent(). At least, they do in AS2 (it's not
possible in AS3). There are rare occasions when I still use the old
approach -- for a quick banner ad, say -- and I do so when that's the most
In your case, there may not be an immediate advantage to converting your
#include code into a bona fide class. (Of course, there might be after all!
Only you can determine the answer.) The general reason for writing
something as a class is to make it portable; that is, conveniently reusable.
I'm in the middle of a tutorial series at CommunityMX.com right now that
describes a class for wiggling the characters in a string of text. I'm sure
you've seen plenty of nifty text animations in Flash ... the ones where,
say, characters fly in from the side and flip into place. This sort of
animation requires individual text fields for each character, so that each
character (each text field) can be animated individually.
To make this potentially tedious effort reusable, the routine that
creates all those text fields can be wrapped up in a function, then called
from any frame after the function's definition (including the frame in which
it appears). To make things even easier, the function (and any related
functions) can be wrapped up in a class. This reduces the amount of code
that appears in the timeline -- which is also true of your #include code --
and, in the case of the wiggling text, can be as easy to use as this:
var wt:WiggleText = new WiggleText("Here's the string");
wt.x = 200; // position the wiggle text
wt.y = 300;
The WiggleText class works just like the Date class, or the Array class,
or any other convenient "building block" in the ActionScript arsenal.
Writing a class gives you an actual *object* that can be manipulated like
any of the native objects in Flash. If the concepts behind your #include
code can be distilled into a reusable object -- something flexible and
configurable -- then it will probably help your workflow, in which case
writing it as a class is the right thing to do. If not (but if you're
interested in writing classes), then you can leave it as #include for the
time being and experiment with the concept in another venue. Until it
becomes fluent. When class writing makes sense on a gut level to you,
you'll know when the practice is worth it in a given usage scenario.
A chess coach often suggested that I not make a move ... until I had
thought through all the reasons why moving that particular piece was a good
idea. Sure, I could study opening moves ... I could memorize which moves
were among the group of "right things to do," but until I understood why --
and agreed that reason was right for my game -- ... well, you get the idea.
Co-author, Foundation Flash CS3 for Designers
"Luck is the residue of good design."
Thanks very much indeed! I hope you were able to lift a good part of that response from existing material otherwise I'll feel guilty for having taken so much of your time.
> Thanks very much indeed! I hope you were able to lift
> a good part of that response from existing material
> otherwise I'll feel guilty for having taken so much of
> your time.
No worries! :) It didn't take very much time. In any case, I hope my
pragmatic approach makes sense for you. Recommended best practices become
recommended for a reason -- often unique per practice. For better or worse,
some of them become so popular, their reasons get lost in the hustle of the
trend. When that happens, I feel it's important to ask "why" and decide if
the reason is indeed valid for my own purposes.
Adobe Community Expert
Dev blog, http://www.quip.net/blog/
"Luck is the residue of good design."