This is the mail archive of the guile@cygnus.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] |
Craig Brozefsky <craig@onshore.com> writes: > [CLOS's method precedence order is] 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. By arbitrary I mean that while there is a rule to chose the specific method, whether it is the "most specific" or "most appropriate" rule is not something necessarily obvious. By "wrong" I mean having read some paper discussing method precedence order. Now I don't remember if the paper was about CLOS or Dylan, but I do remember the paper proposing better rules. Of course there is nothing wrong with learning from recent reseach to design a CLOS-style system but improving on it - if you like CLOS-style sytems. > 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. Consider the one of the classic motivations: Drawing different kinds of objects of different kinds of displays/printers. This is only interesting if it is extensible in both dimensions: One can add new graphics objects as well as new display types. Now suppose I want to draw something for with there is no exact match. Do I go up the hierarchy looking for the closest matching picture or for the closest matching display type? You have to define the rules for what methods somebody has to add when they add a new display, as well as what methods someone has to add when they add a new picture type. My feeling is that using single dispatch makes it easier to structure and enforce this structure. I could be wrong; I really would like to see a paper discussing the pragmatics and extensibility issues of using multi-methods to solve a problem like this. --Per Bothner Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner