On 5/5/06, Paul D. Fernhout <[EMAIL PROTECTED]> wrote: > Of course, you probably don't have a Self-like environment for Javascript. > :-) Or is there one? I've never done much with JavaScript.
Javascript is a prototype-based language deriving directly from Self. Emulating inheritance-type OO is possible, but kind of a hack, mainly done for folks who are new to prototype-based languages. > Designing programming systems is so easy when you stop caring about > performance (at least in the short term). :-) But the advice I was given > long ago is, slightly updated, is: by the time you get it debugged and > anyone has noticed it, computers will be fast enough to run it. :-) That hasn't worked well for Squeak, in my experience. Every time I get a faster computer I try it out, and it's still too slow to use. Also, I think one big reason people are leery of putting all their methods and changes on the root object (or even allowing key objects to be modified) is that introspecting objects to find out what messages they can be expected to respond to is a crucial learning path. That is why Python doesn't let you extend object, string, or int, for example, in order to keep the system predictable and reduce the impact of running dir(string) to something a person can understand. If you did that on a javax.swing.JButton (and Jython implemented dir() so that it showed all available methods, which it doesn't) then you would be overwhelmed with hundreds of options, many of which are implementation details of AWT or Swing, or other widgets, and very few of which are useful to the common expectations and needs of using a simple button widget. So, performance is part of it, but comprehensibility (is that a word?) is the more important part. And yes, I realize that prototype-based languages don't have to be like that, but when you can add methods to root objects, the tendency is to do so, and it can make things very hard to maintain. I know Ruby allows this, but haven't had enough experience with Ruby to know if it's a problem. In Javascript, it definitely is a problem, with libraries like Prototype encouraging "let's stick every method on the root object" mentality and cluttering the namespace. In Objective-C there is a nice middle ground, where you can have a new object layer that adds methods to existing classes when it is imported. So you can add things where they feel *right,* but you're not encouraged to do so willy-nilly. That works for me. > > I'm not really sure how to fit HyperCard into this -- I don't have a > > strong feel for what it really means. I suppose one aspect is that the > > source code is not at the core; instead the card stack is (or whatever > > content-centric metaphor you use), and code is attached there. Ad hoc > > structured code doesn't work that well with a class... you get something > > like: I think Hypercard fits into the conversation because (like in Morphic (Self or Squeak)), you can access the script behind every widget at runtime, as if each widget has its own "view source" window, except editable. Which would be cool for Python to adopt, I think. > But I kind of see HyperCard as more like just one set of widgets in a > Morphic style interface. Yes, very similar ideas. Also the game The Incredible Machine, with it's halo of options around each object (though not editable). --Dethe _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
