3 Replies Latest reply on Jun 4, 2008 12:37 PM by Newsgroup_User

    #include vs import

    Bob Pierce Level 1
      I'm trying move towards a more oop approach in my coding but often wonder how far to go. My sites are entirely in Flash and load all the initial .swfs in sequence behind a progress bar until the home page can go active, after that the loading sequence continues behind the scenes until the whole site is loaded. I've cleaned up the code for this loading sequence into a set of functions with a single initiating call and put it in an .as file which I #include. 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? The code runs only once and I easily re-use it on multiple sites by storing the .as file in a common folder.
        • 1. Re: #include vs import
          Level 7
          Bob,

          > 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.)

          http://www.quip.net/blog/2006/flash/museum-pieces-on-and-onclipevent

          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
          convenient route.

          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.

          http://www.communitymx.com/abstract.cfm?cid=ECBF0

          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.
          ;)


          David Stiller
          Co-author, Foundation Flash CS3 for Designers
          http://tinyurl.com/2k29mj
          "Luck is the residue of good design."


          • 2. Re: #include vs import
            Bob Pierce Level 1
            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.

            Bob
            • 3. Re: #include vs import
              Level 7
              Bob,

              > 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.


              David Stiller
              Adobe Community Expert
              Dev blog, http://www.quip.net/blog/
              "Luck is the residue of good design."