*for this sprite only* blocks

[cameron8299]

in working on converting something i initially wrote in javascript over to snap, what ive been doing is making blocks 'for this sprite only', as im using clones in this particular project, and im not sure why you cant just put (for ex)

which you can put this inside of another 'for this sprite only' block (with this inner local block running for 'some clone' and not whatever called the outer local block, as expected), but when this is put inside of a global block definition, it wont let me save it, saying i need to remove the local block inside it. but the local block isnt a part of that context, its being called specifically for the appropriate object.

now i know the script works fine, because i was running the project with visible stepping turned on, and in editing this global block put something like the thing above and watched it go through it and run everything without issue. now i click ok and it says i cant have this.

you can set local variables via

or even use the variables inside of the grey ring and it doesnt take issue with that. whats the deal?

do i really need to have

because i dont get that 'do its thing' block in the menu with a variable in the other slot, i have to take the variable out, choose the block, put the variable back in. and say i updated 'do its thing' and added a parameter. the block inside of the '[] of []' block doesnt update. so i have to take the variable out, re-select the block, put it back in, then set put whatever arguments in the extended 'run >' block. which takes all the fun out of popping in reporters and just generally putting scripts together with custom blocks personally.

i guess im unnecessarily checking 'for this sprite only' and should just make these global blocks but im curious as to what the intended purpose of localizing block is in the first place?

[bh]

Yeah, like you I'd prefer that that work. I think it doesn't because a sprite-local block implicitly knows which sprite it should run in, so even if you tell another sprite to run it, the way you tell it that is by dragging this sprite's local block into the TELL block, and so the target sprite is still running this sprite's block and not its own.

I don't know why ASK and TELL do work for sprite-local variables; I'll have to ask Jens to explain it to me again.

This is why the OF block has that funny notation with the recessed block, and no ring, that doesn't look like any other block. Sprite-local blocks are just attributes of that sprite, so they show up in the menu of attributes in OF. You can't drag an arbitrary expression over the left menu of OF; it just gets you one attribute of the other sprite.

To answer your question at the end, I think the purpose is that different sprites can have different methods for the same message.

[cameron8299]

i went through and un-localized everything and realized i could either

where i just use these in ask / tell blocks, or take in the object as a parameter, like

i started out doing like in the first way, then switched everything to the second way, and ended up with a mess and decided to try again later from the beginning. probably going to avoid objects all together and stick strictly to mathematical representations because as grueling as that can be it at least leads me down direct paths of reasoning that i can look back and understand how i got where im at. this object stuff i often just feel lost

[bh]

Oh, if all the sprites are going to have the same method, then sure, make it global instead of sprite-local!

[cameron8299]

so ok heres an example, say im adding vectors to some program, i could 1: just straight up define globals for every operation;

addVec(vec v1, vec v2) => vec ans
subVec(vec v1, vec v2) => vec ans
mulVec(vec v, num n) => vec ans

2: have an object soley(?souly soly ) whose sole purpose is preform these operations;

Vector.add(vec v1, vec v2) => vec ans
Vector.sub(vec v1, vec v2) => vec ans
Vector.mul(vec v1, vec v2) => vec ans

3: have individual vectors preform these operations on each other/ themselves;

vector.add(vec v) => vec ans

3.5: have these operations change the vectors own values;

v1.add(v2) => v1

3.75: no, only sometimes, keep both;

v1.addeq(v2) // updates v1 literally setting v1 to v1 + v2
v1.add(v2) // returns new vector = v1 + v2

4: operator overload;

v1 + t * (v2 - v1)

ok perfect world i just do #4 until i get to dot product, normals, abs, normalizing vectors, cross....

do i put

Vector.dot(v1,v2) => res

or make it so

v1.dot(v2) => res

what about abs, which is length right, does a vector have a length the needs to be gotten from it or does the length need to be taken of the vector? do you say vector.length or length(vector)? allow me to apply this to numbers because vectors are just numbers when you get right down to it now, do you ask 3, ' hey, whats your value? ' and it says 'oh, its 3' or do you walk up to 3 and apply it to your process of determining values of things and come up with '3' ? what in the world is 'value' even in the first place? something you find or something that reveals itself to you?

well if im sitting here just making up values AND their meanings then i am neither finding value nor stumbling across it, because theres nothing there thats valuable in the first place, you dont just say 3 is three because i want it to be a thing for there to be three of something no FIRST there was three of something THEN we decided to call it three

my point? i dont know. people blow it off like its a silly question but cant answer it. and they act as if they have better questions to ask and answer, easier, questions. sour grapes said the fox.

[bh]

@cameron8299

soley(?souly soly )

solely.

@cameron8299

3.5: have these operations change the vectors own values;

I vote for functionl programming wherever possible. So, no for this one.

About v1.add(v2) versus add(v1,v2): I don't think there's a right answer to this. In the case of addition, which is commutative, the symmetric notation makes more sense to me, but if we were talking about subtraction I'd see more of a case for v1.sub(v2).

(Of course these days in Snap! you can just say v1+v2, but you are asking a general question so let's talk about multiplying vectors, which isn't just a termwise scalar multiplication, so that option is ruled out.)

I think each programmer's aesthetic sense about these things depends on how they grew up. I'm a Lisp child, so having a global procedure that takes the two vectors as inputs feels really natural to me. Jens and Bernat are Smalltalk children, so the v1.foo(v2) notation feels natural to them, except that really they'd say v1 foo v2, which doesn't look quite so kludgy.

Never mind vectors for a moment and imagine you're implementing the underlying + on scalars. Well, in a computer there are these two different kinds of numbers, integers and reals, so in Smalltalk notation you have to implement integer.+(real) separately from real.+(integer), and it gets quadratically hairier if you also have exact rationals and complex numbers as primitive data types in your language. For abstractions built on top of the primitive arithmetic operations, you can take advantage of polymorphism and just have one method for all numbers, but down at the bottom level it gets messier. So I think that's a weakness of the Smalltalk approach in which everything is a method of one object, vs. generic functions. On the other hand...

@cameron8299

when you get right down to it now, do you ask 3, ' hey, whats your value? ' and it says 'oh, its 3' or do you walk up to 3 and apply it to your process of determining values of things and come up with '3' ?

This is the great strength of Smalltalk. Everything is an object, so if you imagine asking something like 3.value() the answer would be the same 3 object you started with -- this would be the identity function. All those other languages that call themselves object oriented are half-hearted about it, with user-visible non-object data types, so you end up with kludges such as wrapper classes and case-sensitive type names (integer vs. Integer).

@cameron8299

people blow it off like its a silly question but cant answer it.

It's not a silly question; it's a great question. But sometimes seemingly simple questions have really complicated answers. Is light a wave or a particle?