This is the mail archive of the email@example.com mailing list for the guile project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Per Bothner <firstname.lastname@example.org> writes: <sounds of Julie Brown> MOP fight tonite, doobee do wop, doobee do wop, do wop! > I have no CLOS experience. But I won't let that stop me from > expressing my opinion ... > * The method precedence order is arbitrary, and (supposedly) "wrong". Poo poo! It's pretty straightfoward, haha, with the most complex part being the class precedence topological sort for determining the specificity of parameter specializers to determine the most specific applicable method for a given qualifier via a simple left to right comparison of the congruent lambda lists of each method with the presence of a parameter specializers named (eql <object>) trumping everything else. This is assuming that you are using the standard argument precedence order for that generic function. The applicable methods are then applied according to the specified method combination for the generic function. <catch breath> It's not arbitary, and I don't see where it is wrong. But I would hesitate to implement it in it's full glory for a scheme object system. > * I'm not convinced that multi-methods are worth it. They are more > difficult to implement efficiently, they make it more difficult to > figure out what is going on, they remove the modularity advantage > that conventional object-oriented languages have (that methods are > associated with their classes). Well, given that it's not uncommon for someone to attempt to abstract a process which has dependencies on the types of two or more or it's operands, the language might as well support it rather than make everyone make their own version. I don't see how they make things more difficult, a left to right comparison just doesn't seem that complex and convoluted to figure out. As far as methods being associated with their class, that's not because we have multi-methods, that's because we have "generic functions". It's not hard to put your methods and classes together in a package anyways. I personally see multi-methods as a requirement for a scheme object system. > * I'm concerned that efficient compilation and static analysis > seem to be difficult. Indeed. CLOS is not exactly a compiler optimization geeks wet dream. But then again, it's not meant to be static by design, so you really can't blame it. I would like to see a sheme object system retain most, if not all of the dynamicism of CLOS tho, but with a simplified and reduced MOP. I really find tiny-clos to be a good example of what I want in a scheme object system, with a few macros wrapped around it, an optimized implementation, better integration with the usual type system, and maybe a slightly more flexible method combination mechanism, it would rock.