3 Replies Latest reply on Jul 10, 2009 1:17 AM by tinylion_uk

    SDK4 States name values, strings and constants

    tinylion_uk Level 2

      this message is a bit all over the place I know, it's something that's been on my mind for a while.

       

      Seeing as we all use States to some degree or another (I use them a lot!) I wanted to ask who you all feel about having to always use the actual string value rather than some type of compiler constant. I really don’t like having to use the actual string name value throughout the non mxml code.

       

      Especially in .as code I just don’t like having the actual string values in the code. It just doesn’t feel right to me. I can think of no other situation where I wouldn’t use a constant of some kind. I if want to refractor my code or just change the string value of the state I’m having to make sure I’ve fond all of the occurrences of the string. I would never use a string like this in my general code style. I assume neither would any of you.

       

      I know using constants as we have them now in AS3 aren’t what I’m after here. What I would like though is to have a constant like I did in my old assembler programming days. Just one that is replaced throughout my code at compile time with the value.  Just a project wide global constant.

       

      I’d must rather use something like

       


      def: EDIT_STATE = “edit_state”

       

      <s:State name=~EDIT_STATE ... . . ..

       

      current State=~EDIT_STATE ....

       

      or something like that, or something similar. I’m sure you get my point.
      I know you’ll be looking at that thinking well there no difference and in that code there’s not really I grant you but state names aren’t usually that simple :-)

       

      I just don’t like having the actual string scattered through the code.

       

      Another thing I’m wondering, but haven’t looked into I must confess, is this. Is there a way to make more use of ‘state name’. the way the new state model works in mxml is great being able to use:

       

      property.stateName is prefect. In the same way I talking about above, it couldn’t feel so clean if we had to use property.”actual-state-name-string”, it’s just messy isn’t it. yet it’s what we have to do when using states in the rest of our code.

       

      is there a way to use stateName in our as code rather than the actual state string value?

       

      I’m sorry t his email is a bit rambling, and I hope you get what I’m trying to say.

       

      I’d be interested to hear, what you think of this, how you deal with state names in your code, and how do you feel about repeating the actual state value string throughout your code.

       

      Thanks for tacking time to read this.

       

      cheers
      glenn

        • 1. Re: SDK4 States name values, strings and constants
          tinylion_uk Level 2

          Please excuse the typos etc. thanks

          • 2. Re: SDK4 States name values, strings and constants
            matt_chotin Level 3

            Hey Glenn,

             

            Didn't respond earlier as I was waiting to see if others replied.  Having constants for State names as well as other attributes like Events has been something we've discussed.  We really just haven't figured out the right way to get things implemented so that it's useful/readable in markup and makes sense in AS code.  So we're very open to the idea, but since we haven't come up with what we think is a quick and elegant solution we have devoted our priorities to other things.  If folks want to get together and come up with a detailed strategy we'd be more than happy to discuss.

             

            Matt

            • 3. Re: SDK4 States name values, strings and constants
              tinylion_uk Level 2

              Hi Matt,

               

              I totally with you on this, and it's why I hadn't posted on it before.

               

               

              I sat and really thought about what I'd do if I had the 'magic code wand', but have yet to really see how it would work. I do know that I'd rather not be using strings.

               

               

              I agree this is NOT a priority, not even for me. It's just a esoteric change so in truth isn't really important, but it just somehow feel wrong to an old school programmer, as I'm sure you agree. No question that as things are it all works just tinkerty-tonk (err that my way of saying good by the way lol), it just looks and feels wrong. This is not a good enough reason to divert needed man hours away from other things, not at the moment anyway.

               

               

              I think my absolute dream solution would be a whole new type of constant, a compiler constant. A strongly typed value that can be used to simply replace values at compile time. This would also be able to be expanded so a compiler constant could be used in a compiler conditional statement use for compiling blocks of code.

               

              It's something I miss in any language that hasn't got it. My background was as an assembly programmer then c++ and its the lack of these type of compiler defines i miss most.

               

              I think I'd always be most comfortable with the following

              Defining compiler constants

               

              /* Compiler Constants */

              #define DIVIDEND_PTR:int=8;

              #define DIVISOR:uint=12;

              #define REMAINDER_PTR:number=16;

              #define STATE_INIT:String="startState";

              #define PRODUCTION:Boolean=true;

               

              Conditionals

              #if

              #ifdef

              #else

              #ifndef

              #elseif

              #endif

               

              #if PRODUCTION = true

              [] or {} or whatever

              ...

              ... some code to compile

              ..

              #elseif PRODUCTION = false

              ..

              ... or compile this code

              ...

              #endif

               

               

              It's all fairly standard c type stuff, but would just be so handy. Especially as we move more into an enterprise market space. It's not even like it's an actual change to the actionscript language, not as such. Of course there are things there we'd all like, abstracts etc but I think this could be doable.

               

              Again I know this is low priority, but well I may as well write my thoughts down see what other have to say. (lol, nothing most likely

               

              Cheers Matt (good to have you back from holiday - who else we all going to moan at!)

               

              Cheers

              Glenn