Also I was planning on doing a "drag to transclude" thing, as in DDV instead of relying on names.
Yeah, once you're dragging around references to variables instead of typing in names, all the parent.parent stuff can go away. Just drag variables from anywhere in the ancestry into the definitions.
I imagine that the variable would typically appear in the definition as a bare name, with no qualifier, and hovering over it would highlight the card of the object it references. (The name would appear with a qualifier only if there is a closer variable with the same name. So the parent's x would appear as [parent's x] to disambiguate it from the object's own x.)
But now the nesting gets confusing: If we were to add another Moving Light Clock to Scene and modify its Light Clock child, does that change also affect our first Moving Light Clock?
I was imagining that the overriding happens only in the context of the top-level object in the editor (in this case, Scene). When you're editing the Scene "class", you can't affect the Moving Light Clock or Light Clock "classes". You can change Scene's *instances* of those objects -- you can override a particular light clock's variables, and maybe even add variables and child objects to it -- but your changes don't affect the Light Clock class. Scene performs these alterations when it instantiates that Light Clock.
(In DDV, after you instantiate a sub-picture, you can add new variables to that instance of the picture, which you can then use in overriding definitions for that instance. Here, I instantiate a star and add a new variable to it, but the original Star picture is unaffected: [ddv-add-variable.mov] )
It seems unexpected and unsafe to me that you can alter Light Clock while editing Scene -- I'd expect that I could create Scene, do whatever I like within its little world, and then delete it, and be certain that I didn't accidentally modify anything outside of it.
Maybe the thing to think about is allowing for these local overrides/modifications, but then having some means of "extracting" a modification back into the class definition, when you want it to be shared. For example, a variable that has been overridden could offer something like this:
On Jan 2, 2015, at 3:40 PM, Toby Schachman wrote:This is really interesting!Totally agree about giving child objects names.The really new thing (to my thinking) is the scoping with the parent keyword. I think it does make reading the "source code" more clear as where the variables get "looked up" becomes obvious.The part I will need to get my head around has to do with whether a property is "overridden" or its original value. For example, if we look at Light Clock here:<image.png>Light Clock's "time" property is overridden. It is set to "parent.clockTime" but in the original Light Clock diagram its time property is set to some constant value (because we had to "start concrete" with some value).But now the nesting gets confusing: If we were to add another Moving Light Clock to Scene and modify its Light Clock child, does that change also affect our first Moving Light Clock?I suppose a way around it is to just "deep clone" everything when you drag something in so every value is very concrete but I think this is unsatisfactory to the types of adjustment you'd want to make, like turning the photon from a circle into a star or whatnot.Something I've been thinking about is having variables that can be used in multiple diagrams. For example, say I wanted to change the photon's color from orange to yellow and also change the zigzag plot line to the same color. It would be nice if I could make a variable that lived at a higher level. My planned solution to this is to have "folders" of diagrams and each folder can define variables that are in the scope of all the diagrams within it. So you'd have a "Time Dilation Explainer" folder that had some top-level configuration variables (colors, etc) that were then referenced from multiple diagrams within.Alternatively, this is possible in your mockup: just put that color variable in Scene and reference it with parent.parent.etc. (though I think multiple parent.'s will be cumbersome).So anyway, I will think about this more. The column view to show all the relevant variables is very appealing. But I'm not yet sure about the modularity of the proposed scoping system.Also I was planning on doing a "drag to transclude" thing, as in DDV instead of relying on names.Thanks for mocking this!Toby