You should help me convince Jens that we need a notation in which the options don't have to be given in a particular order, something like this:
(I spent ten minutes trying to make a screenshot including the mouse cursor for the second picture and failing but you get the idea.)
And each of the options should be able to have defaults, types, etc.
Nice idea but I think that's a major shift that's unlikely to happen
Menu's are used everywhere in Snap! to select what fills the slot - not to change the slot label.
So the idea goes heavily against that philosophy unfortunately
I'm not changing the slot label; I'm adding a slot, and keeping the ? slot the same.
Oh I see, I should have been clearer! In those pictures, the words in parentheses are commentary, not really meant to be there. It'd actually look like
Sorry for confusion.
P.S. And I don't think it'd best look exactly like an ordinary menu input; maybe more like
or something. Not like an upvar either, some new graphic. For example:
Jens is better at that aspect of design than I am. :~)
It will be an insane mess. And impossible to interpret such a script.
Snap.V10, JS, you can make something like this to denote optional parameters in a GIVEN order but omit the non-set ones.
With modified Snap, non-set items can be hidden and expanded on demand (arrow) or with focus. This way the input list may be handled consistently.
Those concepts were discussed already, in the thread started by Simon, 2-3 years ago.
I've opted for a lookup reporter used this way (Snap.V10, JS)
enum formal parameters of the custom block.
.
This version (Snap.V9, JS) works by enumerating internal block variables of the custom block
That would be great if there were a way to attach the helper to the main block in the palette. Maybe in v10 when we can reorder the palette I'll be happier with it. Maybe we can have a feature to attach comments to palette blocks... But what I really want would be
But the version with a zillion arrowheads in a row makes the user remember which option is where.
PS I don't agree with
Keyword optional arguments are commonplace in the Lisp world, and I think some other languages too. Of course the option slots themselves would remember which option they're filling; Snap! wouldn't have to parse the title text to figure it out.
I know for a fact that python has that. Heck, they even have positional only arguments, and keyword only arguments (by default, all arguments can be positional and keyword at the same time).
I personally wish javascript had keyword arguments, because it's annoying to type null for a bunch of arguments that you don't care about, just to get to the one you do (and this shows up a lot in the snap source code, it's not a fault of jens, it's a fault of javascript).
Ditto for Snap!! :~) Maybe people like @cymplecy and @dardoro and Jens would like the idea better if we talk about "keywords" instead of "options," and we can use a 
symbol as the graphic for the menu...
But, sigh, I seem to be hijacking a thread again. Let me split this... Done!
It's a generic block, not a dedicated helper.
The slot is filled dynamically, with JS, based on the enclosing block definition.
I don't think that named parameters are the seed of evil 
But if you want the optional parameters to be "sparse", i.e. fill in 3 out of 20, it's better to use a dictionary/list.
Countless optional parameters appear usually in the context of the procedural generation of the markup (HTML, XML, SVG) . It's quite a narrow class of problems and, usually, not the best way of doing things at all.
Also for practical reasons, you may create a generic version of the function with many parameters and overload it with the simplified versions using common parameter sets.
Do you really see any advantage of being able to
goto( x:0, y:0);
move( y:100, x:50);
goto( y:-100, x:-50);
arc( x:50, radius: 100, y:50);
Oh. Then you have to look for it somewhere else in the palette. That makes it too hard to use keyword inputs, unless we had a way to make one appear easily without using the palette, sort of like "ringify" to make a ring appear even though officially the ring is a block in the Operators palette.
No, not at all. Most inputs should be positional, and always visible.
But think about the WRITE block. It could have a bazillion possible inputs: font, style, size, underline?, strikethrough?, align (left, right, center), subscript?, superscript?, slope (of the whole line), and so on. Jens adamantly refused to start down that path, because he could see that it was a case in which if you give the users an inch they'll want a mile. But keyword inputs would allow all the complexity anyone wanted, without making the block a mile long. And if you just want to right-align the text (in a given width; that would be another keyword input), you wouldn't have to click through a zillion arrowheads to find that option.
Dictionaries are fine in the implementation; in fact, it'd be okay if the & widget presented a dictionary to the block's script, rather than a zillion separate inputs. But you don't want to make the user build a dictionary as an explicit input, because that doesn't tell the user what the options are! You want to show the user a menu when they click the &.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
