Re: [Python-Dev] PEP 246: let's reset
At 01:49 AM 1/17/05 -0500, Glyph Lefkowitz wrote: On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote: One type is the extender, ... By contrast, an independent adapter ... I really like the way this part of the PEP is sounding, since it really captures two almost, but not quite, completely different use-cases, the confusion between which generated all the discussion here in the first place. The terminology seems a bit cumbersome though. I'd like to propose that an extender be called a transformer, since it provides a transformation for an underlying object - it changes the shape of the underlying object so it will fit somewhere else, without creating a new object. Similarly, the cumbersome independent adapter might be called a converter, since it converts A into B, where B is some new kind of thing. Heh. As long as you're going to continue the electrical metaphor, why not just call them transformers and appliances? Appliances convert electricity into useful non-electricity things, and it's obvious that you can have more than one, they're independent objects, etc. Whereas a transformer or converter would be something you use in order to be able to change the electricity itself. Calling views and iterators appliances might be a little weird at first, but it fits. (At one point, I thought about calling them accessories.) If nobody likes this idea, it would seem a bit more symmetric to have dependent and independent adapters, rather than extenders and independent adapters. As it is I'm left wondering what the concept of dependency in an adapter is. It's that independent adapters each have state independent from other independent adapters of the same type for the same object. (vs. extenders having shared state amongst themselves, even if you have more than one) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
Phillip J. Eby wrote: Heh. As long as you're going to continue the electrical metaphor, why not just call them transformers and appliances? [ ... ] Next we'll see Appliance-Oriented Programming ;-) Just ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
At 10:21 AM 1/17/05 -0800, Guido van Rossum wrote: Heh. As long as you're going to continue the electrical metaphor, why not just call them transformers and appliances? Please don't. Transformer is commonly used in all sorts of contexts. But appliances applies mostly to kitchenware and the occasional marketing term for cheap computers. The electrical metaphor is cute, but doesn't cut it IMO. Adapter, converter and transformer all sound to me like they imply an as a relationship rather than has a. The has a kind feels more like a power tool to me. By the way, another use case for type declarations supporting dynamic as-a adapters... Chandler's data model has a notion of kinds that a single object can be, like Email, Appointment, etc. A single object can be of multiple kinds, sort of like per-instance multiple-inheritance. Which means that passing the same object to routines taking different types would do the right thing with such an object if they adapted to the desired kind, and if such adaptation removed the existing kind-adapter and replaced it with the destination kind-adapter. So, there's an underlying object that just represents the identity, and then everything else is as-a adaptation. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
At 09:15 AM 1/16/05 -0800, Guido van Rossum wrote: Given the many and various issues with automamtic adaptation (transitivity, lossiness, statelessness, and apparently more still) that might be a better approach. Actually, I think Clark, Alex, and I are rapidly converging on a relatively simple common model to explain all this stuff, with only two kinds of adaptation covering everything we've discussed to date in a reasonable way. My most recent version of my pre-PEP (not yet posted) explains the two kinds of adaptation in this way: One type is the extender, whose purpose is to extend the capability of an object or allow it to masquerade as another type of object. An extender is not truly an object unto itself, merely a kind of alternate personality for the object it adapts. For example, a power transformer might be considered an extender for a power outlet, because it allows the power to be used with different devices than it would otherwise be usable for. By contrast, an independent adapter is an object that provides entirely different capabilities from the object it adapts, and therefore is truly an object in its own right. While it only makes sense to have one extender of a given type for a given base object, you may have as many instances of an independent adapter as you like for the same base object. For example, Python iterators are independent adapters, as are views in a model-view-controller framework, since each iterable may have many iterators in existence, each with its own independent state. Resuming the previous analogy of a power outlet, you may consider independent adapters to be like appliances: you can plug more than one lamp into the same outlet, and different lamps may be on or off at a given point in time. Many appliances may come and go over the lifetime of the power outlet -- there is no inherent connection between them because the appliances are independent objects rather than mere extensions of the power outlet. I then go on to propose that extenders be automatically allowed for use with type declaration, but that independent adapters should require additional red tape (e.g. an option when registering) to do so. (An explicit 'adapt()' call should allow either kind of adapter, however.) Meanwhile, no adapt() call should adapt an extender; it should instead adapt the extended object. Clark and Alex have proposed changes to PEP 246 that would support these proposals within the scope of the 'adapt()' system, and I have pre-PEPped an add-on to their system that allows extenders to be automatically assembled from @like decorators sprinkled over methods or extension routines. My proposal also does away with the need to have a special interface type to support extender-style adaptation. (I.e., it could supercede PEP 245, because interfaces can then simply be abstract classes or just like concrete classes.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote: One type is the extender, ... By contrast, an independent adapter ... I really like the way this part of the PEP is sounding, since it really captures two almost, but not quite, completely different use-cases, the confusion between which generated all the discussion here in the first place. The terminology seems a bit cumbersome though. I'd like to propose that an extender be called a transformer, since it provides a transformation for an underlying object - it changes the shape of the underlying object so it will fit somewhere else, without creating a new object. Similarly, the cumbersome independent adapter might be called a converter, since it converts A into B, where B is some new kind of thing. Although the words are almost synonyms, their implications seem to match up with what's trying to be communicated here. A transformer is generally used in the electrical sense - it is a device which changes voltage, and only voltage. It takes in one flavor of current and produces one, and exactly one other. Used in the electrical sense, a converter is far more general, since it has no technical meaning that I'm aware of - it might change anything about the current. However, other things are also called converters, such as currency converters, which take one kind of currency and produce another, separate currency. Similar to independent adapters, this conversion is dependent on a moment in time for the conversion - after the conversion, each currency may gain or lose value relative to the other. If nobody likes this idea, it would seem a bit more symmetric to have dependent and independent adapters, rather than extenders and independent adapters. As it is I'm left wondering what the concept of dependency in an adapter is. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
