Sunday, March 26, 2006

More unfinished musings

So if a dispatch function/closure represents an object, then around-advice on the dispatch function is extending an object. Can a closure be cloned using primitives in Scheme? If so, then closures + aspect-oriented programming == prototype-based object system. The downside to the closure object system is that code is not shared. For cases where the clone dag is deep (large with a small branching factor), not sharing code is a good thing. For cases where the clone dag is wide (large with a large branching factor), sharing code is a good thing. How does one decide which slots will behave like class slots and which slots will behave like instance slots in the clone? Does the closure object necessarily need the concept of a slot at all? It could all be defined in terms of reactions to messages, some of which appear to cause state changes in the object. How does Prometheus handle this? Speaking of, a type could be defined either in terms of the clone dag, where children of a node are types; or type could be defined purely in terms of the interface supported by an object (if it looks like a duck, walks like a duck, quacks like a duck...). What kind of type safety optimizations can be made in a prototype-based language? Is it reasonable to be able to freeze changes to the clone dag in order to optimize method dispatch and slot mutation? Can freezing easily be undone, allowing the developer to resume modifying the objects in the dag interactively? Hmm...


Post a Comment

<< Home