youre quoting "should" i havent used that word once. im going to argue about what 'should' / 'shouldnt' be as little as possible. im talking about what can be done and what will be done by those willing to do it.
maybe a bit of an exaggeration, but i guess a bit of insight into your perspective. let me do the same,
from what im gathering the great big evil for you is the malicious use of features that are too trusting towards the user, granting them potential means of wreaking havoc setting fires around the community site and blowing up computers in the classrooms.
i guess theres a balance to be met between providing an open enough space to exercise creativity while also a secure enough space to do so safely.
i dont think you should enable users to rewrite their machines operating system in snap. i also dont think you shouldnt. i would like the meta programming stuff simply because its fun and i am naturally inclined to implement these features myself. but this pretty much does only run on my device. ive shared things in the past that utilize the js block and add some feature, but then you have to trust some guys arbitrary javascript held together with tape and band aids to do what he says it does and, not take over your machine. set fires. what not.
and im talking about things that people want, people like, and snap lacks. like more input types that exist and are very clearly used in the primitive blocks. and whats the whole idea here, byob, but only jens gets to use the color picker in his blocks? the if else variadic block, i made before you did! but thats not portable, you cant use it in your projects. its not like a real block that you can save in your project and will load up again later. its just crazy to me that i have to go through all that just to build literally like one of the first blocks i wanted to make. so im all isolated here in my corner with my beloved js function block exercising the potential to wreak havoc but maintaining good will because ultimitely i find more satisfaction in making things that people want and like, but yet still remains the fact that nothing i make that is recognized in the default configuration nor will it be solid unless you decide to implement it in an update.
but just keep this in mind. as things are currently. i could write a malicious program in snap utilizing the js block, mask it as some fun program that people want to try, but really i dont know trick people into thinking they disconnected and need to log back in and you could see how this could become an issue. im not going to do that. at the same time nothing is stopping me from doing that. this is what i see as a safety concern. maybe someone driven by different motives might not be so pure in their intentions. your fixing potential injury by giving us this sharp medical equipment. 'do it yourself and dont hurt anyone'. letting people select menu items i dont know i feel like your concern may be a bit misaligned from the actual danger. but thats just what i think. im lacking your experience so, you know, grain of salt. sand. whatever.
ok so you want to go as far as including these menus:
as well? i think if there were a way to just target objects (like actual morphs) it would literally be the exact same process. im sure thats not what you want but you know every individual block has its own context menu, certain multi input slots have a menu, you would need to be able to navigate through this. which is entirely feasible, ive done this to various extents before just playing around, heres that block rewritten in snap format (obv with some custom helpers)
these blocks are clearly meant to appeal to my own style and familiarity but the dot parenthesis format can stylized however fits snap. im pretty sure inside the %obj . %fn ( %...args ) block is literally just a call reporter. ditto with the block version with run.
and thats not even what youre getting at but im just saying imagine if you could implement this stuff literally in snap i mean talk about meta programming... i really love this kind of extensibility theres just so many hacks and workarounds required to even pretend its a thing.
edit: also i think it would be so cool if in the input editor how you have to write a javascript function and return a dictionary or options and yadda yadda, there was a block editor where you could build a script that returns the menu or even like to somehow define custom inputs / input types but idk im not gonna dream too hard.
That's actually the whole reason why the js block became disabled by default. There was someone who used the js block to fake the snap website, and collect user's passwords.
more slot types including color slots with color pickers are already in dev and been in there for a while. What frustrates beyond reason is that I keep adding features as fast as I can but the more features I add the more complaints I'm getting about allegedly missing things from ... this community gets me down in many ways, and worst of all is the tone of "of-course-ness" associated with these complaints.This sucks. Why don't y'all complain to Guido or Mitch about all your brilliant rules and laws that "of course" have to be obeyed by language designers?
Yeah, while we are disagreeing, nothing is going to happen in this direction. I was just saying what it would mean to take Eisenberg's Law really seriously, not suggesting that it be implemented right now
And also because nobody has said "of course" on this thread except you just now. But yes, I'm willing to say there are things language designers should do. I don't have to say it very often, these days, because (not counting Guido of course :~) ) language designers all understand the power of anonymous procedures in a language. (Instead, these days, I argue about case sensitivity with people I think of as colleagues, rather than enemies and/or idiots, namely the r7rs gang.)
Again, maybe I'm expressing myself badly. By "by default" I don't mean that everything is necessarily visible to the user in a fresh Snap!. Some things, for example, are in libraries. Some things, not just JS Function, are visible in the palette only if a box is checked in Settings. That's all fine.
If you actually look at all the context menus, you'll see that a surprising number of their items are available to programs. That's great!
I don't think dev mode is a good place to hide things you think are too cognitivy. That's what libraries are for, although we should try to avoid having a bunch of one-block libraries that could maybe be combined. (I'm allowed to say "we should" because I'm part of the "we," especially with respect to libraries.)
Dev mode, imho, is for things that aren't finished yet, and for things really of interest only to developers or to users who want to be developers, such as PROCESSES and the other census-ish ones in Sensing. Putting something in dev mode attaches a hidden "you'll be sorry" to it. Is that the case with SAVE AS COSTUME? Is it not finished yet? (Not rhetorical questions; I really want to know.)
