why the forever if block removed? bring it back now plz
It was removed because it could easily be replaced by an if block inside a forever loop, making it pointless.
But if you really want it, you can easily make it into a custom block.
predicate is a Boolean (unevaluated)
command is a Command (C-shape)
Its not pointless bcz it saves space.
It's pointless because it saved one block space, that's practically nothing.
Something you should learn is that @jens (Oh my god I have a habit of pinging people) deletes some libraries he thinks would be unnecessary, not useful, or just pointless.
I think it's because if the G&S library could get something like a User's Username, then it can do a whole lot more.
Wow, you got many things wrong. Jens doesn't like the getters and setters library, because he thinks the stuff it does should only be done through the ui, not code. Another thing is, the getters and setters library doesn't access the snap cloud at all. Getting the username is really just grabbing a variable that was set when logging the user in. Getting the username does not make an api call to the snap cloud (well, in the getters and setters library).
Hey, give me some credit. My point was that @jens has removed libraries in the past because of them being unnecessary or something. The rest is just irrelevant stuff. You don't need to worry about anything but my point.
Granted, what I put were examples, but they were bad examples.
This is one of those times where flagging would work in favor with a group of people.
First time i got flagged wow
I'm sorry, it's just late, and I'm not trying to be mean. I just didn't want you spreading misinformation.
Too late now i will send news with a project
I don't think either of those things is true. When he gets mad and goes on a rant threatening to delete things, he doesn't always mean it.
On the contrary, when faced with a serious security breach using the JS Function block, rather than remove it, he went to the trouble of implementing a mechanism so that users can still use it in their own projects while still protecting third parties.
As for Create Variables, yes, Jens hates it, because he doesn't think you should program that way, but I work hard at convincing him that his opinions about our users' programming styles aren't reasons to make Snap! design decisions. (Otherwise we'd get rid of list mutators!) And in fact Jens reimplemented that library to work with Snap! version 7.
As for Getters and Setters, Jens hates it, but I think it's super important on principle (Eisenberg's Law), and we have worked out the compromise that it's the only library not converted to v7, so it works only if you enable the JS Extensions flag.
We have deleted libraries because the purpose of the library was redone as Snap! primitives, for example, but even that hasn't happened very often. Oh, and there was the LEAP Motion library that went away because the company that made them redid their firmware in an incompatible way, so it stopped working.
I see that there has been some further discussion since I started responding, but I don't think the point you wanted to make is really true, not if you're suggesting that we delete libraries regularly.
And anyway, FOREVER IF wasn't a library, but a primitive.
Create vars now uses primitives.
What exactly do you mean by list mutators, and what would you have (although apparently not enforce) us use instead ideally?
A mutator is a procedure that changes some stored value. SET is a mutator for variables. The list mutators are ADD, INSERT, REPLACE, and DELETE.
We promote functional programming, which means that instead of changing a stored value, you make a new one. In particular, we like the higher order functions MAP, KEEP, FIND, and COMBINE. See sections IV.C and IV.D (pp 48 ff) of the Reference Manual.
Oh yeah they really do feel out of place to me. Especially since the SET uses the 'variable dropdown menu' and for the list ones you actually place the list into it. vs. (although I'm sure there's a reason for it).
IMHO, SET, INHERIT, SHOW and Hide. is the only necessary one for variables and lists (which could mean no CHANGE BY block) for variables including lists.
Correct me if I’m wrong, someone with more knowledge than me: I believe it’s because lists are first-class, unlike in Scratch. Because in Scratch lists are essentially variables but are not stored in variables, you can have a drop down of all lists: because Scratch knows how to separate them. However, in Snap!, lists are stored in variables. How does Snap! know what variables are lists and which are not? I believe that is why.
Wait- how do you use MAP, KEEP, FIND, COMBINE (etc) to replace ADD, INSERT, REPLACE, and DELETE? I’m confused haha
Exactly. In Snap!, lists are a data type, just like numbers or text strings, rather than a strange flavor of variable.
But "lists are stored in variables" isn't quite right, because you don't have to put a list in a variable. You can, for example, say
They're not one-for-one replacements. But typically you use list mutators in loops, like this:
and in functional programming you just use
and don't change the original list at all.
Ah. I was thinking about use cases where strings would need to be stored.