get property :
set property :
call method :
run method :
set method : (i like this one especially)
and then pass that variable through the first input slot in any of the blocks. when the first slot holds an object, the second, dropdown input slot menu will show all properties / methods (according to the block), including those of its prototype chain.
there's some examples in the project showing correct usage.
This is an interesting idea, elegantly implemented.
My question is, why use JS objects rather than make native Snap! ones? See Chapter VIII of the manual. Native Snap! ones would make the code usefully examinable, would avoid the need for JS Function, and would teach the Big Idea that a language doesn't have to be advertised as "object oriented" to support OOP.
trust me ive been trying. ive read / walked through that section a few times, and though i am very impressed with the structure and functionality, i have a few issues with that approach i cant get past.
first of all, i think the code in the manual is unnecessarily difficult to follow / read, and to anyone who hasnt already grasped the concept, i think will be scared off by all those nested scripts / functions. i myself still cant quit wrap my head around the clone of block.
secondly i dont want to remember and type in manually properties and methods, i want a way to know which arguments correlate to which parameters (if any) were set. i know this could be somewhat satisfied by creating custom blocks with specific syntactical representations, but heres some ideas i find alot more satisfying that arent available in snap as is.
last thing ill say is, i cant stand being shown the entire function when i report it. maybe a way to set the visual return value differently to something like a table or have collapsible c blocks so you can see block by block a summary without having to look at the whole thing.
i wouldnt call it teaching as im still learning myself. its more about being able to present what ive learned, i heard somewhere something along the lines of for you to really understand a concept, you should be able to explain it clearly with simple terms. and in that, i think theres an important distinction between 'explaining to' => others (for their understanding) vs 'explaining from' <= you (to test your own undestanding). are you trying to be understandable or understood? i think its better to allow people to learn what they want (regardless of what you want them to learn) rather than try to teach them what you want (disregarding what they want to learn). and by 'want' i mean think, feel, believe, etc. its alot easier to learn than teach anyways. you cant teach me a thing i wont learn. but i can learn anything youre willing to teach. therefore, you(or i) only really can teach someone something so long as they are willing to learn what you/i am willing to teach.
didnt mean to go into a whole philosophical delineation lol but it did strike me odd you saw it as an interest in teaching the thing rather than an interest in the thing in itself
I'm not going to fight over the difference in emphasis between teaching and learning! My car's license plates say KIDS LIB and I explain to people who ask that I love teaching and hate schools.
oh i dont mean that all toward you individually i was just kind of branching off and sometimes things line up in my head i just need to get them down before it goes away. and sometimes ill use my you's and i's interchangeably because i cant figure out whether to take the 'you' perspective or the 'i' perspective. but i really mean both! (need an objective i/you) but i just want to clarify that bc i know that probably came off awfully arrogant but i really didnt mean it as a personal thing, and honestly you seem to have respectable values which i can agree with so no worries here!