Object implementation

through my many many attempts at trying to make javascript objects accessible and intractable via snap blocks, this is probably my most simple / stable library.

get property : untitled script pic(20)

set property : untitled script pic(21)

call method : untitled script pic(22)

run method : untitled script pic(23)

set method : untitled script pic(24) (i like this one especially)

the easiest way to use these is to assign some javascript object to a variable, such as

untitled script pic(25)

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.

It won't open for me.

try now

it works now.

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.

Very nice :slight_smile:

Maybe could be altered to look more Snapish?

image

And maybe put in its own category?

We're going to end up regretting implementing custom categories, aren't we? When each library has six of them, and people collect a dozen libraries in a project...

Maybe the custom ones can be made into a dropdown menu so that they don't clutter up the interface (or something like that anyway) when/if it becomes an issue.

But something like this needs to be spread between sensing/variable and operators or its own custom cat

I for one, am VERY happy to see the end of grey custom blocks :slight_smile:

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.

my interest in the javascript method is it allows you to get a handle on any morph, say a block morph, and see all the properties/methods, view and alter them and see the results without having to ever touch the console. at least thats the idea.

Ah, I see. I got the impression from your first post on this thread that you were interested in teaching OOP in general.

This is in a distinguished tradition. Back in BYOB days, Jens made block representations for the Smalltalk code implementing BYOB. :~)

P.S. Yeah, we really really need internal definitions.

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

Huh. I went back to the first post on the thread to check. I guess I was interpreting "through my many many attempts at trying to make javascript objects accessible" as implying that you yourself understood them but had trouble explaining to others. Maybe because I'm a teacher myself, and also Snap! is all about learning altogether.

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!

Likewise. :~)