11 Replies Latest reply on Jul 28, 2006 7:52 AM by Peter Lorent

    Basic question about Actionscript and symbols

    eric76 Level 1
      I like the object oriented features of actionscript (2.0). One thing confuses me tho, namely the combination of symbol classes and constructors. Since symbols can't be instanciated by new SomeMovie(...), but rather has to be created with attachMovie(), it seems to me that there is no use of constructors for symbols. Instead you have to send an init object in the attachMovie() call. This seems to me to be lacking in logic. It would be much more logical if you could do:
      var m = new MyMovie(constructor arguments...);
      destinationClip.attachMovie(m);

      Am I correct that this way of doing it is not possible in current actionscript?
      And second, don't you agree this would be a more consistent use of the actionscript language?
        • 1. Re: Basic question about Actionscript and symbols
          Peter Lorent Level 2
          What you are describing is merely inheritance in OOP: class myClass extends MovieClip
          The extra feature Flash throws in is that you can connect that class to a movieclip in the library. And you initialize such an object by putting it on the stage or by attaching it to a timeline of some object. Hence, you don't need a constructor. But you can have one if you like and put in the init object you mention (though it's not adviced and error prone):
          class myClass extends MovieClip {
          public function myClass(){
          this._x=10;
          this._y=10;
          }
          }

          No, you still can't use the new keyword. But, you should only extend the MovieClip Class if you need all or at least most of the functionality of the MovieClip Class. In all other cases you should use composition where you save the functionality of the MovieClip Class in an instance property: private var my_mc:MovieClip;

          Is this symbol classes and constructors thing inconsistent? In traditional OOP, yes. But in some cases, like when you want to distribute class libraries, you MUST extend the MovieClip Class so it's just something unique to Flash. And you should just know when and how to use it.
          • 2. Basic question about Actionscript and symbols
            eric76 Level 1
            I'm not sure i follow u completely. To begin with u are confirming that u can't call a constructor for a movieClip, since u create them with attachMovie(), and that therefore u don't need constructors. But my point is it would be more consistent to create all objects by calling their constructors (whether or not they are MovieClips). This is especially true if the constructor takes arguments. If it is not possible to call the constructor, you will have to send an init object, which I understand u think is bad (but that's how I do it now). Or alternatively, attach the clip, and then manually set some variables in it. But in both cases u lose the possibility of abstracting a way the movieclip's internals. The good thing about a constructor is, that u only have to send some parameters, without accessing the movieclip's internal variables directly.

            For example:
            clip s = new MyMovie(arg1, arg2, arg3);
            attachMovie(s);

            would be much nicer than:
            attachMoive("MyMovie", "s", 1);
            s.variable1 = arg1;
            s.variable2 = arg2;
            s.variable3 = arg3;

            A somewhat better alternative might be to have an initialization method, that also could make calculations on the parameters before setting the internal state (just like a constructor can):

            attachMoive("MyMovie", "s", 1);
            s.init(arg1, arg2, arg3);

            this still have the ugly side of having to create a init method that does what the constructor is supposed to do for ordinary objects, and so invitees u to initialize MovieClips and other objects in different ways. Also the attachMovie method forces me to create a variable name for the clip (ie doesn't allow anonymous clips, like arrayOfBalls.push(new Ball());).
            • 3. Re: Basic question about Actionscript and symbols
              Peter Lorent Level 2
              >> To begin with u are confirming that u can't call a constructor for a movieClip
              No, that's not what I'm saying. I said you don't NEED a constructor but you CAN have a constructor. You just don't use the new keyword to INITIALIZE the object. When you have a constructor it will be automatically called.

              >>but my point is it would be more consistent to create all objects by calling their constructors
              Yes, but attaching a class to a movieclip is a special construct and should only be used when your object needs all or most of the functionality of the MovieClip Class or when you want to distribute class libraries. In all other cases you should use composition instead. Think of it as an exception to the rule.

              >>you will have to send an init object, which I understand u think is bad (but that's how I do it now)
              No, having a constructor is error prone. But if you have a constructor you could put your init code in the constructor (when the init code is the same for every instance). Using the init object is fine.
              • 4. Basic question about Actionscript and symbols
                eric76 Level 1
                First, I just wanna thank u for replying. I still have some follow up questions that I think are of interest:

                About the first issue of constructors u say they automatically gets called. But isn't it true that only a constructor that takes no arguments can be automatically called? Because, how could a constructor call with arguments MyMovie(x, y, size, etc), be automatically called? My point is, that it would be more neat to send the parameters thru the constructor, than thru an init object. Also, I wonder why u think constructors are error prone. Maybe they are error prone exactly because Flash/actionscript invites to an inconsistent way of initializing MovieClips and other object instances?

                Second, u say that attaching a class to a MovieClip should be avoided unless all or most of the functionality of the MovieClip Class is needed. I usually attach a class a MovieClip that needs some code to describe its behaviour. In practice, I think the only essential method that I need from MovieClip is the onEnterFrame(). Are you suggesting that it would be better to skip onEnterFrame in individual objects, and rather loop over some array to make all objects get their command to do their thing? I thought the good thing about onEnterFrame was that I could avoid having to traverse arrays of objects, and instead let Flash itself call all objects that need to be updated each frame.

                Third, I would like to repeat the benefit of not having to create variable names as attachMovie requires. For instance, assume alot of clips are being attached to the same containing clip. Now u have to make sure that all attached clips get different variable names, or strange things will happen. But if attachMovie just took a reference to a clip as parameter u would avoid that problem.

                If u know some document that discusses these issues, i would be happy if anyone had a link to it. My suggestion to the Flash developers is to make MovieClip objects consistent with ordinary objects.

                • 5. Basic question about Actionscript and symbols
                  Peter Lorent Level 2
                  >>Are you suggesting that it would be better to skip onEnterFrame in individual objects, and rather loop over some array to make all objects get their command to do their thing?

                  That is where you are going wrong. Then you should be using composition. See attached code. I see a lot of classes that extend the MovieClip Class and it seems like the first thing people do. Wrong! It's not proper OOP.
                  Attaching a class to a movieclip is a SPECIAL feature and should only be used in some cases.

                  >>My point is, that it would be more neat to send the parameters thru the constructor, than thru an init object.
                  And if you would use the proper way - composition - you can.

                  >>My suggestion to the Flash developers is to make MovieClip objects consistent with ordinary objects.
                  No. In some cases we need this feature.

                  In the attached example I have a movieclip (simple rectangle) on the stage with an instance name 'my_mc' placed in the upper left corner.
                  • 6. Basic question about Actionscript and symbols
                    eric76 Level 1
                    You say that attaching a class to a movieclip is "not proper OOP. Attaching a class to a movieclip is a SPECIAL feature and should only be used in some cases." I would still say that it is not inproper OOP in general, only improper i Flash, exactly because Flash is inconsistent. If it was consistent, the proper OOP way, is to strive for type completeness, in the sense that all types should be handled the same way. Why should movieclips be a special type of object that behaves differently from other objects? I bet the only reason is that the Flash designers saw some technical dificulties in implementing movieclips consistently. Still it would be the proper OOP way IMO.

                    Your example of using composition instead looks like a possible way around the problem. Still, there is another problem with that example, because of actionscript's strange scoping rules. For instance the code in the class where u create the onEnterFrame (see my attachment "Your example"): Now I can't even call methods in the "owning" class, since actionscript has dynamic scoping rules. One way to solve that: keep a reference to the owning class in the movieclip. One uggly side effect is that u need to put a dummy variable in the class to fool the compiler (see attached code "My example").

                    All this, including the uggliness of how u have to invent a new variable name for each movieclip when attaching to the same target, I think shows, that there is something awkward about this whole bussiness. My oppinion is still that it would be way better if MovieClips could be made consistent with normal objects so all this special treatment and work arounds becomes unnecessary. And Pls actionscript designers, make the scoping rules static!

                    • 7. Re: Basic question about Actionscript and symbols
                      Peter Lorent Level 2
                      Well, your entitled to your own opinion. But, first learn (a lot) more about AS and specifically OOP before you start giving advice to the developers.

                      • 8. Basic question about Actionscript and symbols
                        eric76 Level 1
                        I do know alot about OO (I've studied the theoretical aspects of it and done much OO programming in Java which I think is a great language), but I sure don't know all the intricasies of actionscript - hence my questions at this forum. Thanks for the tip on Delegate, it will make things easier (though I still would prefer static scoping rules as default, and the use of extra features like Delegate only when u wanna use some odd scope for your call).

                        I am still conviced tho that, the reasons for movieclips being inconsistent - and thus forcing these work arounds with classes that handle the clips by composition - are purely technical. No sane language designer would on purpose implement elements of the language that behave inconsistently (so that type completeness is lost) - only would they allow it because the technical difficulties of achieving it was too hard. So I would respect an answer from the developers that said "sorry but its just too hard to fix this right away", but I wouldn't accept an excuse saying "inconsistency is principally the right choise in this case".
                        • 9. Re: Basic question about Actionscript and symbols
                          Peter Lorent Level 2
                          >>and thus forcing these work arounds with classes that handle the clips by composition
                          No, composition is to be considered the 'standard' way to use OOP in AS. That's not a work around.
                          Flash just offers an extra feature and that's attaching a class to a movieclip. To be used for instance when you create a component. Has nothing to do with developers not beeing able to program this differently. It's just a feature of the program. Your confusion might be that you think extending the MovieClip Class is the first choice. It's not. Composition is in almost all cases the way to go.
                          • 10. Re: Basic question about Actionscript and symbols
                            eric76 Level 1
                            As I've been saying all the time: the reason attaching a class to a MovieClip is just an extra feature is just that: it is implemented as an extra feature. My point is that if actionscript and Flash was integrated more fully, the reason to have to handle MovieClips in special ways (with composition) would dissapear, and u would have a more consistent design environment. (Maybe what I am hinting at is really to make Flash only a visual aid for a fully Flash-capable language (like in so many other visual designers)).
                            • 11. Re: Basic question about Actionscript and symbols
                              Peter Lorent Level 2
                              Have a look at AS3. Maybe things evolved to your likings. Otherwise, who knows what the future brings.