Manage Prototype Creep

(Galen Menzel) #21

Just to be clear, @gnoli’s current $OnAdd probably looks something like


Meaning that, like @wajakob, he is using the prototype mechanism to copy all the relevant metadata. (But unlike @wajakob, he removes the prototype designation after he is done using the prototype, so the list of prototypes doesn’t grow unmanageable.) If he no longer uses prototype assignment to do this, his $OnAdd will have to look like


as in @mdavidson’s solution. In fact, if @gnoli makes this adjustment, he will basically be using @mdavidson’s solution. Seems like a good fit here.

(Paul Walters) #22

I wouldn’t use a prototype as a container for other notes (say, prototype MyReference – based on modifications of the built-in Reference prototype). Instead, I would create a new note (MyContainer) to use as a container, and assign MyReference as MyContainer’s prototype.

Why? Because the children of prototypes also become the children of notes that are assigned that prototype. (Easy to test and see this for yourself.) In your case, you are “de-prototyping” the container so the risk of mistakenly creating notes you didn’t intend to create is low.

But unless you intend for a prototype’s child hierarchy to be inheritable, it’s not a best practice to use prototypes as containers, in my opinion.

(Galen Menzel) #23

Ah I didn’t know that – many thanks!

(Michael Prenez-Isbell) #24

very elegant solution.

(Mark Anderson) #25

See, specifically the parts about prototypes ‘bequeathing’ children.