On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > The problem I have sometimes in making my proposals clear to you is that, > at the level of abstraction I think on, there are often multiple ways to > carry out a useful/usable implementation, but you seem to want to > understand one *particular* implementation, even though I'm trying to > propose an approach to the solution, rather than a particular solution.
Oh, it would all be so much easier if we could all be in the same room for a day... The problem often seems to be that I don't have the imagination to come up with a suitable implementation for the abstraction you are describing, and at that point it's no longer an abstraction but an arbitrary string of words to me. Those words may brim over with meaning, but there are so many choices that it's hard to guess which one is meant. [[As an analogy, someone with a lot of HCI experience once pointed out to me that when you show a code fragment to someone who isn't used to programming, they tend to only see the words and lose the punctuation, so for example they would see "self.__getattr__(x)+y" as "self getattr x y" which loses a lot of meaning. Maybe I have the same problem with some of your examples.]] I guess an abstraction ideally needs to be described by formal semantics, not by a hypothetical usage example. Since formal semantics are often hard to come by, I'll settle for an implementation sketch. For example, I really couldn't fathom what you meant for addmethod(iter, ...) to do. It suddenly became completely clear once you said "addmethod(x, ...) calls x.__addmethod__(...)". > However, when I present you with a particular implementation, you then pick > holes in the implementation itself, or the tradeoffs made to render the > example simple. That's unfortunate but can't always be avoided. I'm thinking that I criticize the implementation in order to understand the abstraction better. Since the implementation is often the only clue I have for understanding the abstraction, if the implementation oversimplifies things or has an obvious hole in it this distracts from the understanding. > If I knew what tradeoffs you would prefer ahead of time, > then I could make my examples match the desired tradeoffs, but in the > absence of that information I can only fall back to describing a general > concept. That's why I wish we had more direct face-to-face interaction. > So we tend to go back and forth between abstractions rejected for > lack of specificity, and specific things rejected for their particular > nature. :) Perhaps I should try giving implementations explicitly > labelled as prototypes and stating that there are other ways to do the same > thing? I don't know. In general, I find implementations that draw too strongly on PEAK or RuleDispatch distracting because I'm not familiar with their semantics or terminology and I'm in the "self getattr x y" situation again. At this point I think I understand the defop proposal and I understand addmethod. But I think I could use some help with hasmethod. Suppose I wanted to write the sendmail example using hasmethod. (I know it can be written differently, but other examples may need hasmethod, and I'm familiar with the sendmail example.) Could you should (a) what the example would look like and (b) what would / could go on behind the scenes to make it work? Bonus points for an attempt to show that it can be implemented efficiently. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
