"Brent Dax" <[EMAIL PROTECTED]> writes: > Dan Sugalski: > # Okay, here's another shot at the semantics for objects. If folks, > # especially non-perl folks, would look this over and chime in, I'd > # much appreciate it. > ... > # Attributes are local to a class in an object's inheritance hierarchy. > # An object can have one "foo" attribute per class in its inheritance > # tree. > # > # Attributes are considered class-private, so a class will normally > # only see its own attributes. There will be a mechanism to see all the > # attributes for an object, though. Code outside a class won't see the > # attributes--they aren't exposed. > ... > > I honestly don't care much about such languages, but how is Parrot > going to support classless languages like JavaScript? Are such > languages going to have to fake it with anonymous classes, or will > we make sure that you don't *really* need a class behind an object?
Hi, I'm new to this list and haven't had a chance to grovel through the old archives yet so please forgive me for jumping in in the middle of things. Anyway, what about languages that don't attach methods to particular classes--languages that support generic functions and multimethods (i.e. a method is dispatched at runtime based on the type of more than one of its arguments.) I ask because I started looking at Parrot (and joined this list) because I was interested in the idea of writing a Common Lisp that runs on Parrot. I had looked at the CLR as a possible target and found it too tied to the single-dispatch model of methods "belonging" to particular classes. I was hoping things would be more flexible here. Was I hoping for too much? -Peter -- Peter Seibel [EMAIL PROTECTED] The intellectual level needed for system design is in general grossly underestimated. I am convinced more than ever that this type of work is very difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expense. --Edsger Dijkstra
