Inherited Variables

Quick question re inherited variables:

I define a SpriteA and a few vars specific to it.
Then on another SpriteB I change its PARENT to SpriteA.
And SpriteB gets all the vars of SpriteA reflected as local var black icons.
So far so good.

Then I change SpriteB PARENT to NONE.
And all the variables inherited change color to light grey local var icons in the SpriteB display.
Why is that?
Is it that when the PARENT link is broken the vars are converted to local vars and kept for safety ?
Even this is kind of OK.

But then I restablish the PARENT of SpriteB as SpriteA.
Now the local vars display show the grey local var icons only.
But underneath them are a new set of INHERITED black local icons - NOT VISIBLE.

And if I delete the top layer of visible local grey var icons one by one, then underneath is the inherited black icon set !

Is this normal ?

I was expecting that:

  1. when PARENT is changed to none, the first set of inherited icons to be deleted.
    OK I understand why these might revert to local vars.
  2. when the PARENT is changed again a second time to the same earlier parent, then the newly created INHERITED black local icons to be displayed in addition to the grey old local icons.

Having them on top of each other and only one set visible is very confusing !

Finally, a side effect of all this is that one ends up with a lot of extra local icons in the process of repetatively changing PARENTS.

When you separate from your parent, you get copies of everything. You could argue for losing the variables, but presumably you made local variables in the first place because they are used by local methods. And you wouldn't want to lose other inheritable things: Think about your position and direction! So, everything is copied.

Reconnecting to a parent is more complicated. I can certainly see an argument that having two sets of variables is confusing. I can also see an argument that it's safer not to lose the old values of your variables until you explicitly say to inherit your parent's values.

But I am not seeing this behavior about multiple same-name variables. Could you send a movie or something?

What I am seeing is inconsistencies depending on how a clone relationship is set up. I'll look into that.

Sorry, could not figure out the movie part !
But here is a scenario that is easy to follow:

  1. Create a Sprite called P

  2. Create a Sprite called C

  3. Declare two LOCAL vars for P: Pvar1 and Pvar2
    Should look like this - local icons LIGHT colored :
    Inh1

  4. Then set PARENT of Sprite C to P.
    This makes P vars show up in C - inherited icons DARK colored :
    inh2

  5. Now set PARENT of C to NONE.
    This makes the inherited vars of C change color to LIGHT colored LOCAL vars:
    inh3

  6. Now set PARENT of C back to P.
    And the var icons are not changed to DARK as before.
    Neither are the newly created (if any?) INHERITED icons shown!

  7. Now if you delete one of the visible LOCAL vars, eg: Pvar2; the inherited one shows up underneath:
    inh5 inh4
    As you can see, undeleted Pvar1 is in LOCAL color LIGHT, and the newly visible inherited Pvar2 is in color DARK.

I hope this was possible to follow and duplicate.

Thanks.

Ah, I see. There's really no "underneath" involved; once you delete the local one, the parent's one is available to be inherited. I thought I understood you to say that you had several local variables with the same name.

Jens is of the opinion that what it does is correct. Stay tuned for the results of the argument...

Hi bh,

After your last message I looked into inheritence and same name variables, and found out about "Variable Shadowing". It's definition totally explains what is happening and I finally got it. WIthout being aware of that rule, I was thinking the wrong way.

I then searched the SNAP! Reference for similar info. And it is somehow mentioned in the inheritence section but not in terms of "Variable Shadowing", and kind of burried in the midst of other info.

To make it easier to understand, it might be helpful to refer to a herarchy of local variables from a SPRITE's perspective. Please feel free to use/modify the proposed write-up below as you see fit. It is my attempt to clarify this issue, and it probably could use a technically correct editing.

Thanks.

Hierarchy of LOCAL Variables:

INHERITED VARs
LOCAL VARs
SCRIPT VARs

  • INHERITEDVarIcon INHERITED VARs:
    Another Sprite's LOCAL VARs can be inherited by a Sprite by declaration of PARENT. These are designated by a DARK colored icon in the VARIABLES section.
    If the receiving / inheriting Sprite already has LOCAL VARs with the same name. then the LOCAL VARS have precedence and they SHADOW the INHERITED VARs. In other words, INHERITENCE does not happen (or is dormant) and the LOCAL VARs are shown with LIGHT colored icons instead.
    However, if the INHERITENCE condition is ON (a PARENT is declared for a Sprite) and one deletes a LOCAL VAR that has the same name as an INHERITED VAR, then the inheritence takes over and the INHERITED VARs show up in the Sprite's scope, designated by a DARK colored icon.

  • LOCALVarIcon LOCAL VARs:
    A Sprite can have LOCAL VARs only valid for the Sprite. These are designated by a LIGHT colored icon in the Variables section. However, if another Sprite declares this Sprite as its PARENT, then these LOCAL VARs can be passed on to / inherited by the other Sprite. These VARs then show up designated by a DARK ccolored icon in the other Sprite's Variables section. See "same name" caveat above.

  • SCRIPTVarsIcon SCRIPT VARs:
    These are valid only in the SCOPE they are defined in and cannot be INHERITED or referred to outside of the definition scope. These are temporary: they are created and destroyed as one enters and exits their scope. There is an exception case of REPORTER scripts that needs to be understood - refer to HELP on "script variables" block.

Thanks. I like the idea of talking about the hierarchy of variable scopes, But I think the reference in your text to the particular situation you discovered is too specific. Mostly, sprites don't take on parents after being created; they are created as clones of a parent.

I'll massage this next revision of the manual. (Soon... better be... I'm way behind...)