4 ms·

I did a bit of development for the Newton back when: I wrote Waba for the Newton (a JVM) and Hemlock. But I never could figure out why NewtonScript had two dif

I did a bit of development for the Newton back when: I wrote Waba for the Newton (a JVM) and Hemlock. But I never could figure out why NewtonScript had two different inheritance paths. It seemed overly and unnecessarily complex. (1) Was this language feature inserted to allow for the parent frame gizmo present in the Newton's GUI toolkit? Or did was the toolkit design constructed after the fact to take advantage of this unusual language feature? (2) Would you have done it differently in hindsight?

wrs 7y ago
The language and toolkit evolved in parallel. Self had unlimited prototype slots and that seemed like too much. The two we ended up with had specific names that reflect their intended purpose, which became clear as we wrote the toolkit and the apps that used it. The idea was that you inherit from two things: the parent (normally meaning the parent view) so you can have variables scoped to a view hierarchy, and the prototype so you can inherit behavior. The original Newton hardware had hardly any RAM (I think the NewtonScript heap was about 50k) and the prototype pointer was also essential to allow most of the object to reside in ROM (there was 4MB of ROM). So bottom line, we had two specific reasons for prototypes and that became two specific slots. Self took a more general approach (it is a research language, after all). I’d have to think a while about whether to do it differently now. As a comparison, look at the schemes JavaScript frameworks come up with for scoping data to a view hierarchy. In Newton that was just a straightforward variable reference. Remember that NewtonScript was not intended as a general-purpose language — thus the name!