Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.
Thanks!
What browsers show this problem? Google Chrome
Please share an example project (if possible).
Describes the steps to reproduce this issue.
use this block:
What does Snap! currently do?
show some snap block code as an output
What should Snap! do instead?
I'm not sure but I don't think it should do what it does right now.
The domain of JOIN is text (words, sentences, numbers). So if anything, that should give an error message. But in general we've made the choice to avoid domain tests, which slow down execution of correct code for the sake of checking incorrect code. That's why you see things like that.
Channeling Jens, I suggest that emphasizing textual representations is a kind of disbelief in the ability of visual representations to meet programmers' needs. If we're going to extend the domain of JOIN, it should be by inventing superstrings in which visual representations can be concatenated (I guess each counting as one "letter" in the string). We now use lists for that purpose, but the list's own graphical representation sort of overpowers the items.
I mean, I wouldn't say it's "emphasizing". JOIN operates on text, and even in a visual world, there's often uses for text. Reasonable text isn't mutually exclusive of a nice visual representation.
Whether it's a critical feature, well, that's depending on your view. But everything that's visual has a useful text representation -- when it comes to accessibility we'll need everything to have one.
Agreed. But it's not just as good as the visual representation, let alone preferable.
I think we should have something like the old Lisp property lists, on which an object can store, among other things, a VISUAL-FORM method and a TEXT-FORM method, the former a method that reports a costume, while the latter is a method that returns a text string.
We also need to be able to copy and paste the full Unicode character set, as we were reminded recently on Github.
It depends on the context. For some things, a text representation is clearly necessary. And when it comes to accessibility, have to try extremely hard to not believe that text/verbal or any other forms of output are second class, or else they'll become tefl-fulling.
This is essentially how things do work in Morphic. There's a draw method (or a few), and a toString method, which is what's being called by join.
What I meant, I guess, is that if the object is a costume, all else being equal, you don't want to see #[a costume] or something; you want to see the costume. Yes, if you can't see at all, working with costumes is likely to be unrewarding, but the solution isn't to try to find a just-as-good text form; it's to invent activities with sounds, whose preferred representation is to play it!
I wasn't just thinking of Morphic objects. I'm thinking about exact rational numbers, whose internal form is a list of two integers, and whose external form is some flavor of num/den. That's an example where you could have a visual form that has small digits above and below a horizontal bar, with a text form that's just ASCII 3/4 or whatever. Now those are equally good!
Sure, but in the costumes (or any other complex object) case that's probably a different block -- or at least you have a use for two different types of output.
(And that's the same for numbers. Everything has a toString method.)
