Forever if block removed

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.
image
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.

He has deleted the Getters and Setters library (Or at least he's gonna) and the Create Variables library. For the G&S library, it's because you need JavaScript Extensions for the library, it's not used very much, and basically uses JavaScript Extensions to hack into the Snap! Cloud...er...something.

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.

For the Create Variables library, it's pointless because you can use Script Variables, the library needs JavaScript Extensions which isn't really essential if all you are trying to do is to make a game or application JavaScript-free yet make variables using scripts, and no one uses it!

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).

The last thing you got wrong is, you don't need javascript extensions to use the create variables library, it's done using the extension blocks.

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 :neutral_face:

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. untitled script pic (16) vs. untitled script pic (15) (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
Untitled script pic
Screen Shot 2022-06-17 at 11.04.26 AM

They're not one-for-one replacements. But typically you use list mutators in loops, like this:


and in functional programming you just use
untitled script pic (2)
and don't change the original list at all.

Ah. I was thinking about use cases where strings would need to be stored.