Announcement

Collapse
No announcement yet.

overriding a inherited "auto" state fails, without a compiler warning?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    overriding a inherited "auto" state fails, without a compiler warning?

    Hi,

    i just noticed that if u try to override a inherited basestate that is declared "auto" and don't also declare your overridden version "auto" the new code wont be reached.
    This is somehow unexpected, since "Auto" is just a optional modifier and so far i was not aware that a missing "auto" keyword would prevent correct overriding.
    If "Auto" for states is handled like function keywords "protected/private" than at least the same warning should be given, that the state modifier don't match.
    If it is not handled like functions modifiers, than it should correctly use the overriden code, but still use the "auto" behavior from the basestate.

    As a extra note, since "InitialState" can also be used as "Auto" replacement and directly set in the defaultprops, "Auto" should not behave like "private/protected" for functions for my understanding, since this would result in 2 different overriding behavior's, which just depends on the "flavor" u choose to define your startup states.

    Example:

    Code:
    class DroppedPickup
    {
    
       auto state Pickup
       {
    	event BeginState(Name PreviousStateName)
    	{
    		AddToNavigation();
    		SetTimer(LifeSpan - 1, false);
    	}
       }
    }
    overridden to:

    Code:
    class MyDroppedPickup extends DroppedPickup
    {
    
       // overriden version wont be executed, if "auto" is missing, instead the base version is executed!
       state Pickup
       {
    	event BeginState(Name PreviousStateName)
    	{
    		// do new stuff
    	}
       }
    }

    I'm not sure but i suspect that in this example, i actually created a "new" state "Pickup" instead of overriding the org. one. This would be strange since, im also not allowed to create "auto state Pickup" and "state Pickup" in the same class. So it also should not be valid for derived classes. Also "Auto" is a more situational modifier and should not be a part of the state signature for overriding. Since its not uncommon to move/remove the "auto" to a different startup state, which now will result in different behavior/code in the given example, since we now "activate" the overridden code by just removing the "auto" keyword in the baseclass.

    Thx Andy

    #2
    The "bug" is still present in the latest 8623, June 2011 build.

    Comment

    Working...
    X