I think that snap! should support all attributes (in a 
) in a set block. if i 
can support variable reporters and some things in the my block, why not other ones?
Yeah, I have to finish the getter/setter library. I have most global state things, but not sprite ones. I'll bump that up my list...
but I said
Yeah. But that's not likely to happen (I'm guessing Jens won't agree), whereas putting things in a library is easier. I agree your notation would be great, but since there are differences in where and how different attributes are stored, we couldn't implement it as cleanly as I think you're imagining. We'd still have to pull apart the lambda and see which actual attribute you're setting.
but why would that be easier?
(a) I'm kind of in charge of libraries, and (b) Jens is fiercely protective of the Snap! editor itself, but more tolerant of things like this as libraries.
That's not irrational of him. If you take the trouble to load a library, you presumably know what you're getting into, whereas if something in Snap! itself has a weird effect that's not so good.
so you could do 
?
Does the first of those work?
I agree that in principle one reporter is like another. But under the hood variables are quite different from other reporter blocks. And each non-variable reporter has its own code; x position is implemented completely separately from answer, for example.
set value x position to []
is the same as
set x to ()
?
I didn't try it :~|
@4cwefgtw9e587
the reason I want this is a [scratchblocks] set (λ) to [] for {
} :: grey[/scratchblocks]
wait so
set (actual number ) to []
because that would just say
Error: The variable (x pos number goes here) does not exist in this context
can't you use script variable??
of course, that would be a block in the definition, but it would be a custom block.
huh?
I don't get it.
nevermind
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.