Didn't I reply to this already? Shared block instances - logically - also share their attributes, including block (-instance) vars. That's the "reason" for this behavior. It's a quasi-physical model of execution, in synch with Snap's/Scratch's model of executing each "physical" script only in a single Process. Don't use it in places where you share "physical" block instances. You don't like it? fine. But it solves - among other issues - this subject of this thread.
Do You really want block variables to be expression scoped? Not script (like process/thread variables)?
So the same function used more than once has separate variables.
Isn't this narrow scope usefull onlly only for BH lambda expression project?
Also variable values are somehow persistent.
This functions nas a side effect - value is stored.
So that leads to this strange result.
Values are persistent when dragged but lost when copied.
Aren't those variables, initially, handled by "outercontext" so script block scoped?
Thing are getting even weirder. Local block variables are persistent while save/load.
I feel sorry for the teacher that is trying to explain this.
The result seems entirely expected to me if the x blocks are simply reduced to zero inputs - they would retain their previous values
I'd expect that
I'd expect that as well
I doubt very much whether a teacher is ever going to reach the stage of teaching this
It seems to be that the block variable facility is something that could come in useful in certain situations but would not get used in 99.9.....% of projects
It's the sort of thing an advanced student might have a need for.
Until it was mentioned in this thread, I'd never heard or noticed the facility was there (I might have once noticed it in the past but I've never used it)
Did anyone else know about it / use it / found it to be deficient for a project they actually tried to use it in?
Nothing to do with my project. Jens invented this for the purpose he cited above.
Globally shareable (the same for every instance of) custom blocks variable can be also used in "When" but twice as usable for other purposes and without that much unpredictability as shown in my examples.
I insists that this example of trully shared vlocals (crafted from vlocals) has much more sense. Neglecting the fact that setting variable as a side effect of reporter is not that great examples itself.
We're an OOP language as well as a functional language. :~) Everyone who implements a stack has a POP reporter that pops something off the stack and reports it, for example.
Reading Jens's mind, I think the way to talk about this feature is that the definition of the block corresponds to a class, and each physical copy of the block corresponds to an instance, and each invocation of that copy of the block is like sending it a message.
But I actually had a hard time wrapping my mind around this when Jens invented it. I think that that's because Jens has a stronger sense than I do that a block -- an actual "physical" block -- is the bearer of code. Jens talks all the time about how the blocks are the actual program, not just an interface to some underlying text code. I'm more likely to say that the block definition is the program, and reading your mind, I think you think that way too. So the actual blocks aren't interfaces to underlying text code, but they are interfaces to code, namely the code in the definition. I think it probably matters that before inventing Snap!, Jens worked on developing Scratch, which, back then, didn't have custom blocks at all, so it made more sense to talk about the code living in the block rather than in the (nonexistent) definition of the block.
I'm not totally happy about that paragraph; I'm not sure I'm making myself clear. Let me try again... To me, making a copy of a block isn't a big deal. The copy is just a pointer to the Platonic-ideal block that holds the code. But to Jens each copy of a block is its own piece of code. Does that make sense, Jens?
PS If I were designing this feature myself, I'd try to have some more explicit way to fork a version of the block that would have its own name, or in some other way be clearly distinguished from other copies, rather than making that an implicit effect of dragging the block from the palette into a script. And yes, it would also be good to have the equivalent of class variables as well as these instance variables.
Imagine that we took out the SET and ADD/INSERT/DELETE/REPLACE list blocks, so there's no way to change the value of a variable or list. Instead, if you want a different value, you make a new one. That's a functional language.
Put that way, I guess it sounds weird; why would you want to remove capabilities from a language? But functional languages have become important in the real world because of parallelism. Everybody's computer has two or four or eight processors inside, and of course server farms have thousands or millions of them. When code can change values of things, it becomes really important to know the order of events -- does process #2 read the value of some variable before or after process #1 changes it? But with functional code, the computation in one process doesn't depend on events in another process. This avoids lots of really ugly bugs.
I still dont get it
Umm then you're going to have to help me understand what part you don't understand. Can you ask a more detailed question?
make this more English like
Sigh. Did you understand
why would you want to remove capabilities from a language?
Did you understand
Everybody's computer has two or four or eight processors inside
Did you understand
When code can change values of things, it becomes really important to know the order of events
Sorry, does the "nvm" mean I shouldn't reply?
nvm = nevermind
I know the abbreviation, I just wasn't sure if you were using it to say you're giving up on getting an explanation you understand.
I have a hard time trying to fit what You wrote to what I see...
For me, there are two layers of code. It's true that scripts are executed by interpreting the blocks tree itself. But the actual JS code is loosely tied by name of the function (selector) stored as a block property.
Second, the CustomCommands template body is expanded/inlined/cloned when dragged into the script area. There is really no reason to NOT inherit/share the variable frame from a custom template. The idea of controlled inheritance of selected properties is well known and used in Snap!.
What can I say? Jens was trying to solve a particular problem and invented this way to do it. My own pet peeve about it is that there's no way to give the variable a starting value other than zero. But I'm going to stop trying to emulate Jens now. :~/
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.