I think that programmers of every prototype-based programming language find that they eventually need to develop a pattern for class-like abstractions. Here is the one for NewtonScript: http://waltersmith.us/newton/Class-based%20NewtonScript%20Programming.pdf …
-
-
Replying to @awbjs
It would be a significant area to dig into to: https://web.archive.org/web/20070823070757/http://www.dekorte.com:80/docs/protos/ …
1 reply 0 retweets 0 likes -
Also, how does the Treaty of Orlando come into play?https://www.deepdyve.com/lp/association-for-computing-machinery/treaty-of-orlando-C0KfgwLV1q …
1 reply 0 retweets 0 likes -
Replying to @mlhaufe
I’ve always understood that the point of the Treaty of Orlando was that classes and prototypes are duals so there is no point in fighting about which is better.
2 replies 0 retweets 0 likes -
There’s one bit of evidence to suggest that classes are more natural. In a pure functional language, implicit this-binding happens at instantiation time using the same mechanism as lambda variable capture.
1 reply 0 retweets 1 like -
In this context, prototypes break: If you create a prototype, this-binding occurs at the prototype deceleration site. Sure you can create a copy with some fields (functions, variables) replaces with new values, but the old fields will be stuck with the old this-binding.
1 reply 0 retweets 0 likes
Object oriented programming has a completely clear purely functional subset, but it’s only sensible with the class abstraction. There’s no way to capture prototypes without explicit this-plumbing at every call site.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.