On Thu, 27 Dec 2018 21:27:02 -0500, Neil Van Dyke <n...@neilvandyke.org> wrote:
>Stephen De Gabrielle wrote on 12/27/18 4:47 PM: >> I always wanted to ask if the prototype object model is a good >> idea or bad idea? > >I think it's not a bad idea, but I think you probably wouldn't use it >for general-purpose OOA, OOD, or OOP right now. For a long time, OO >overwhelmingly embraced mostly the same class-instance-inheritance >model. Recently, we're seeing some newly popular languages back off >from that very familiar model, including dusting off some ideas like >traits/interfaces and mixins/composition. Given that Javascript is prototype based, it could be said that prototype is the most widely used object model. Not to mention: - Lua - Common Lisp with MOP and some partial implementations: - Objective-C's "categories" extends classes only - Swift's protocol generics extends classes only Then there are languages that can (more or less easily) fake prototyping on top of their normal class-based objects by using reflection and/or runtime compilation: - Python with prototype.py - Perl with Class::Prototyped - Java - Racket ;-) - Scheme - Common Lisp sans MOP etc. Java, Perl, and Python [and probably also Objective-C] certainly count as widely used even if their prototype abilities are not well known. Prototype objects are well suited to small(ish) projects having a single developer or even a small, well integrated team. Where they fall down is in big projects where you want more strict control over the prototypes' use. The notion of being able to "lock" an object against modifications, or restrict it to use in certain modules, is rarely included in prototype based systems. The biggest (IMO) problem with prototype OO is that the lack of a static hierarchy makes the code very difficult (or impossible) to optimize. >Maybe (just speculating, off the cuff) it turns out there's also a place >for prototype object models in symbolic machine learning, in acquiring >some variation on frame-based representations of knowledge. There are many good use cases for prototype objects, but if you are not careful, it is all too easy to screw up. Most prototype systems do little or nothing to protect you from yourself - they are predicated on trusting the programmer not to make dumb mistakes or do stupid things. Languages having fine grained dynamic linking and runtime available compilers - i.e. the ones that can fake it - have eliminated many of the advantages of prototype based objects. [OTOH, there is Java which offers both true reflection and runtime compilation, but actively discourages using either by making both as inconvenient to use as possible.] >> The same question applies to Morphic User Interface Construction >> Environment - good idea or bad idea? Can't Squeak ;-) for Morphic - I've never used it. YMMV, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
