When you define a custom block the actual block name ("s" attribute of element in the XML) is identical to the visible block name (including a representation of parameters). However for built-in blocks this is not true. For example "next costume" block is named "doWearNextCostume".
The actual names of built-in blocks do not seem to appear in the Snap Reference Manual and I can't find them anywhere else. Is there a list somewhere or a method to generate such a list from the code? Such a list would seem very helpful both in terms of working with the XML format, dealing with version-to-version changes, and for avoiding potential variable name overload.
The thing is, the "name" of a block is ambiguous; there's no official name, partly because of the Smalltalk-style interleaving of title text with inputs.
"doWearNextCostume" is a Javascript symbol that allows for reference to the method that implements a primitive block. (It's also used for the filename of the block's help screen.) Really there should be no reason for a user ever to see those symbols. Even the developers don't go around talking about "the doWearNextCostume block"; we say "the NEXT COSTUME block" just like anyone else! :~) So it's misleading to call those symbols "the actual names" of the primitives.
Jens is adamant that a blockspec such as "%s = %s" isn't a block's name either. That, too, is something users should never see. There's no context in which users type in those %foo input type indicators. In the long form input dialog, the types are given user-visible names such as "Any (unevaluated)."
For purposes of metaprogramming, Jens invented a new thing called the "label" of the block, which is the title text with underscores indicating the positions of inputs. That's as close as we come to the "name" of a block, and it's far from a complete specification; it doesn't include the type (shape) or category (color), for example. There are different blocks that have the same label. People's names are like that, too; if you do a web search for "Brian Harvey" you'll find an athlete and a dead rock 'n' roller.
We prefer that users not manipulate the XML that we use for serialization of Snap! blocks. There have been too many reports of "Snap! bugs" that turned out to be malformed user-generated XML.
Hi, one use case for knowing the s attributes of built-in blocks in the XML format is to enable generating certain Snap scripts without requiring mouse actions in the runtime. This may be for example an aid to accessibility (a11y) for those who have visual or motor impairment.
Another issue is that it seems the s attributes may in some cases impact the global namespaces for variables (per posts I've seen about not naming a variable "list"). If that's true it would seem good to know the entire list of dangerous names.
A third issue as I mentioned in my original Q is dealing with temporal change between versions of & when old version XML import code doesn't handle a name change to a prebuilt block.
So to me a list of (block title, s attribute) for prebuilt blocks, or a recipe for making this, would be a useful thing.
This is what metaprogramming is about. You can do that entirely within Snap!, without need for massaging the XML.
AFAIK there's no actual danger with naming a variable LIST. (And, by the way, nobody ever names a global variable LIST; they use it as a formal parameter in a block definition.) The reason we recommend against teachers using LIST as a parameter is entirely pedagogic; it's that an orange oval labelled LIST looks too much like a red oval labelled LIST, representing an empty list, especially when the code is projected at the front of the room. And the entire list of such names is "list."
This is our problem to solve, not yours. The XML file contains the Snap! version number in which it was created, and we keep track of backward incompatibilities. There was a recent flurry of problems with new projects not loading into an old Snap! because of a browser bug causing the cached copy of Snap! being only partly replaced with the new version. Although this isn't our bug, Snap! includes code to try to work around it, and that didn't always work. The problem will be solved before the next official release.
Just leave the XML files alone, and if something in Snap! doesn't work for you, file a bug report.
I'll mention specifically that there is an extension function (Settings Menu -> Enable Extensions blocks) called ide_blocks which returns a Snap! list of all known blocks. From there you can access and manipulate them however you want.
If you do want to generate XML for a particular project, then the Snap! source course is really the source of truth as to some sort of specification. In JS there's an object which defines all primitive blocks and their attributes, and the internal function names (like doWearCostume), but you'd need to treat this as an internal API subject to change.
But to bh's point, there really shouldn't be many invalid names. (~ is a bad name for odd UI reasons, but that's a known annoyance and not something which is actually used as a variable name. )
Thanks for your perspective. As I see it, one of Snap!'s strengths over (for example) Scratch is that it has a straightforward, logical and human-readable XML representation of entire projects. To consider this an implementation detail for Snap! core developers only, not to be otherwise utilized, seems very limiting especially for open source software destined to be used in a variety of ways not necessarily intended by its creators and developers.
Just as one example, assistive technology normally runs outside of a given application or environment: requiring that it be implemented only from within Snap! using metaprogramming is not in my view entirely reasonable, and may not even be possible due to potential lack of access to platform a11y capabilities from within Snap!.
I understand the development & support advantages of an opaque file format. Flash was a comparable overall environment in many ways given its intrinsic stage & sprites and SWF started life as simply the internal format between the Flash developer application and its runtime Flash Player. But soon enough there were compelling use cases for generating SWFs from other applications, people reverse-engineered it, and the format was eventually documented. 99% of all SWFs in existence were probably generated by Macromedia/Adobe apps and as an Adobe alum I'm well aware the other 1% were the source of a disproportionate amount of hassle. But the overall ecosystem was a lot healthier when it became more open (and it only lost out to an even more open HTML5 ecosystem).
Anyway I respect the Snap! development team has their philosophy and as a newcomer and so far just user I'm not in any position to preach. But I do think that since the XML format exists, it will be used (from your earlier post it sounds like that is already happening) and so, as Macromedia eventually learned, it might be the better path to consider that a selling point, not solely a burden.
Do you still have friends there? Could you get them to end their ongoing war with Apple waged by disallowing creating PDFs with active URL links on the Mac?
Yes, we do have users who want to manipulate the XML, sometimes for useful reasons and sometimes just because they know they're not supposed to. (If you provide tools to kids, you have to expect that!) For the useful cases, though, our goal is that you should be able to do everything in Snap! itself, without tweaking the XML. (That's especially true for accessibility; we have to take responsibility for that, rather than rely on user-built kludges to work around our missing features. We know we need to interface to text-to-speech devices; if there are other things we can plausibly do, by all means tell us.)
That doesn't mean you can't do what you want for your own purposes! But you're an experienced adult programmer; you're not really the kind of user we put our effort into.
OT but since you mentioned it - PDF has always been an open format (originally de facto - Adobe always published the specification - and now ISO Standard 32000). So there is no way for Adobe to "disallow" Apple or any of us from doing anything we wish with creating or using PDFs. But there have been various security issues pertaining to active URL links in PDFs (that may be viewed locally rather than in the browser sandbox) so I would presume Apple has unilaterally decided if & how to handle such URL links in both its Preview viewing software and its PDF creation tooling. If Apple is trying to deflect on their implementation decisions by suggesting Adobe Acrobat/Reader software as an alternative, that's on them, not a reflection of any "war with Apple".
Glad to hear it isn't a war, but that's not the impression I got from a web search.
But it's not just Apple applications. Acrobat, Word, and various fourth-party applications I've tried can't/won't make active links either. I've been reduced to installing a virtual Windows machine on my Mac and copying the files there for the last step, replacing all the links with active ones using a third-party Acrobat plugin.
Anyway, thanks for the clarification; I'll try complaining to Apple.
)