I'm sorry I have no idea which category to put this in. But I'm wondering something -- in some libraries, e.g. the MQTT library, when the user wants something to happen when a message is received, they provide a ring that runs whenever a message is received, like this:
It makes sense if you know how the JavaScript code works internally. But I've always found this to be strange, somehow... It doesn't seem that this type of pattern occurs in other built-in/library blocks. For example, the ask block also outputs a deferred output, but it does it by waiting instead of calling a given command in the future. And it's probably just that way in JavaScript since threads can't yield (unless you use a generator function)
So I was wondering if it'd better if message data was instead read something like this, where it waits for a message and returns it. I think this is called polling.
I feel like that would make more sense. What do you think? Is poll-based or message-based better?
edit - ignore this - I was just waking up I think the difference between the MQTT subscribe block and the ask block is that only one ask block can be in use at any one time (e.g two sprites can't ask questions at the same time)
Whereas several subscribe blocks can be waiting for to receive messages completely independently of each other
But having said that, let me play around and see if I can make something simple like you suggest for simple use cases.
[edit - this script shows that its actually waiting
You'll notice that the reported timestamp is only changing every 5000 milliseconds, which is how often I'm publishing the UTC datetime ]
FYI MQTT extension development
The MQTT extension blocks are being updated for Snap! V8 and the new library is available on a GitLab fork - just in case anyone comes across a bug or a missing feature - that is the one being actively developed by myself and Xavier Pi (the original author of the MQTT blocks)
Polling would be using a FOREVER IF block to test for a returned value once per display cycle.
Your notation, I think, is agnostic as to how the waiting is done. It could be implemented (whether in Snap! code or in JS) using either a FOREVER IF or a callback as in the current library. Typically callbacks are more efficient because they match what the operating system typically gives you.
I like your notation precisely for that reason -- it abstracts away the implementation mechanism.
However, the elegance of your notation depends on the fact that the message reports only one value. Is that always the case? If not, your block would have to be a command with upvars to hold the message's return values, followed by an imperative script to make sense of them, or else it'd have to report a list, which the surrounding code would have to tear apart, so it'd be equally ugly and non-functional.
This is sort of the same problem that object oriented programming has when a message has more than one input, and you only get to dispatch on the type of one of them. (So instead of real OOP people use generic functions to dispatch on the types of all the inputs.)
Using the extra subscribe block, it seems to cope with the data rate from joecooldoo's Pen Online project
It's not 100% perfect but I think it would be good enough for a lot of projects
The question is - do we just make the block return the message payload or the received message topic as well?
Background info on MQTT subscriptions
You can subscribe to all messages on a topic by using a wildcard such as name/#. When a message is received by a subscriber to a wildcard topic, then the received topic can be used to determine which actual topic had a message published to it.
So, if the block doesn't supply the received topic, then it would be restricted in how it dealt with wildcard subscriptions
And by the time I've written all this out, I've talked myself into deciding that is should have a received topic upvar as well
Sorry for the late reply but in my humble opinion I'm unsure about using upvars. It is definitely an interesting idea but it's not as... expressive? I don't know how to explain it. (It also reminds me of a convention in C programming, where the programmer declares an uninitialized variable, and passes in the address of that variable to a function which sets the variable.)
