Equivalent of new keyword from JS

In a little project I am making to try and implement classes using lists, I am running into an annoying problem which is that when I change the child object, it modifies the parent as well - i.e. the child is somehow linked to the parent. I had a look in the Snap! manual and couldn't find any solution (at least, not one that I could understand well enough).
Essentially, what I want to find is the opposite of the 'inherit' block, something that stops my variable from inheriting. Another (slightly more accurate) comparison would be having the equivalent of the new keyword in JS. I expect I'm missing something really obvious here but any help would be appreciated.

(here is a link to the project - it explains my problem a lot better than I did: https://snap.berkeley.edu/snap/snap.html#present:Username=adamantpenguin&ProjectName=Classes%20library and please forgive me if this post doesn't make a lot of sense, I am quite tired and probably not thinking properly)

Thanks in advance!

Please see this topic in the FAQ. Ask again if that doesn't explain it for you.

Also please see Chapter VIII of the Reference Manual for the official approved way to invent OOP in Snap!.

Thanks (and sorry), I forgot to check the FAQ and that post did indeed solve the problem for me!

And with regards to the Official Approved Way to Invent OOP in Snap!, I have already looked at that and although that is indeed a much better way to do it, it is not what I am trying to do now.

That's cool. Enjoy!

I was vey interested in your approach to class/instances in Snap! using lists.

So I thought - what is needed - is a proper copy (turns out the term is deep copy)

So as per this thread

There are at least two ways of doing it

I used the id block on your script and it seems to do the job

Hope this helps :slight_smile:

(and please keep posting about it :slight_smile: )

Deep copying data structures is kinda neat, but also kinda not what OOP is really about. One of the big ideas behind OOP is that structures can be in relation to others, and that those relationships are dynamic, i.e. they make something change when something changes elsewhere. In "classical" (i.e. class based) OOP the relationship between classes and subclasses and between classes and instances is structural, i.e. adding or removing a slot in a super-structure gets automatically inherited by its dependents. In prototypal OOP the dynamic relationship also includes the values of individual slots.

Therefore OOP can actually be thought of not so much as duplication (deep copy) but as shallow copying in combination with copy-on-write. That "copy-on-write" part is the hard part :slight_smile:

You completely lost me. I thought I understood this stuff! How I understand class/instance vs. protoype is that in class/instance the instances don't have methods, whereas in prototyping every object can have methods, and can be the "class" of other objects.

What I thought you were going to say is that inheritance doesn't involve copying at all, but sharing of pointers. I don't get the copy-on-write thing.

I just would like to be able to experiment with using classic class/instances to see if certain things are simpler or more complicated using them.

Classes: Subclasses share the same structure (slots, instance variables, methods) as their superclasses, same as instances share the structure (the slots, instance variables) of their class. Changing the structure of a (super-) class also changes the structure of all dependents (subclasses, instances), that's why it's not a deep copy.

Prototypes: Clones share mostly everything with their parent (shallow copy), but when they change the value of a slot it gets copied locally. Hence copy-on-write.

Oh, I see. Is that a general property of prototyping? I thought we'd invented it!

Ah, that would be nice, if we had invented it. But it's actually how they all work. Same in JS :-/

Although, wait, if the child changes a value, there's no need to copy anything! The child changes its shared pointer into a new private one.

well, changing a "shared pointer" to a "new private one" is sort of a complicated technical definition for copy-on-write, isn't it? Especially since now a new slot that holds the pointer must be created.
The point isn't that whatever the value is get "copied", but the slot.

I guess if the child changes a mutable structure, that's when copy-on-write is relevant.