On 2005 Jan 13, at 19:21, Clark C. Evans wrote: ...
Are you _sure_ you have M*N adapters here? But even so,
Yep.
for j in (J1,J2,J3,J4,...,JM)
for i in (I1,I2,...,IN):
register(j,i)
Uh? WHAT are you registering for each j->i...?
The other issue with registries (and why I avoided them in the origional
PEP) is that they often require a scoping; in this case, the path taken
by one module might be different from the one needed by another.
I think that should not be supported, just like different modules cannot register different ways to copy.copy(X) for the same X. One size had better fit all, be it a single specific adapter or potentially a path thereof.
| The convenience of this is undeniable; and (all other things being | equal) convenience raises productivity and thus is valuable.
It also hides assumptions. If you are doing adaptation paths
Not sure if it hides them very deeply, but yes, there may be some aspects of "information hiding" -- which is not necessarily a bad thing.
Ok. I just think you all are solving a problem that doesn't exist,
Apparently, the existence of the problem is testified by the experience of the Eclipse developers (who are, specifically, adapting plugins: Eclipse being among the chief examples f plugin-based architecture... definitely an N-players scenario).
and in the process hurting a the more common use case:
A component developer X and a framework developer Y both have stuff that an application developer A is putting together. The goal is for A to not worry about _how_ the components and the framework fit; to automatically "find" the glue code.
The assertion that you can layer glue... is well, tenuous at best.
If you ever did any glueing (of the traditional kind, e.g. in historical-furniture restoration, as opposed to relatively new miracle glues) you know you typically DO layer glue -- one layer upon one of the pieces of wood you're glueing; one layer on the other; let those two dry a bit; then, you glue the two together with a third layer in the middle. Of course it takes skill (which is why although I know the theory when I have any old valuable piece of furniture needing such restoration I have recourse to professionals;-) to avoid the easy-to-make mistake of getting the glue too thick (or uneven, etc).
I'm quite ready to consider the risk of having too-thick combined layers of glue resulting from adaptation (particularly but not exclusively with transitivity): indeed PJE's new ideas may be seen as a novel way to restart-from-scratch and minimize glue thickness in the overall resulting concoction. But the optional ability for particularly skilled glue-layers to have that extra layer which makes everything better should perhaps not be discounted. Although, considering PJE's new just-started effort, it may well be wisest for PEP 246 to stick to a minimalist attitude -- leave open the possibility of future additions or alterations but only specify that minimal core of functionality which we all _know_ is needed.
| In terms of "should" as opposed to convenience, though, the argument is
| that interface to interface adapters SHOULD always, inherently be
| suitable for transitive chains because there is NO reason, EVER, under
| ANY circumstances, to have such adapters be less than perfect,
| lossless, noiseless, etc, etc.
I strongly disagree; the most useful adapters are the ones that discard unneeded information.
The Facade design pattern? It's useful, but I disagree that it's "most useful" when compared to general Adapter. My favourite example is wrapping a str into a StringIO to make a filelike readable object -- that doesn't discard anything, it *adds* a "current reading point" state variable (which makes me dubious of the new "no per-state adapter" craze, which WOULD be just fine if it was true that discarding unneeded info -- facading -- is really the main use case).
The big picture above, where you're plugging components into the framework will in most cases be lossy -- or the frameworks / components would be identical and you woudn't want to hook them up. Frankly, I think the whole idea of "perfect adapters" is just, well, arrogant.
So please explain what's imperfect in wrapping a str into a StringIO?
| What about "registered explicitly as being suitable for transitivity",
| would that suffice?
I suppose so. But I think it is a bad idea for a few reasons:
1. it seems to add complexity without a real-world justifcation, let's go without it; and add it in a later version if it turns out to be as valueable as people think
Particularly in the light of PJE's newest ideas, being spare and minimal in PEP 246 does sound good, as long as we're not shutting and bolting doors against future improvements.
2. different adapters have different intents, and I think a given adapter may be perfect in one situation, it may royally screw up in another; users of systems often break interfaces to meet immediate needs. In your strawman I can think of several such twists-and-turns that an "obviously perfect" adapter would fail to handle:
- In the 'structure' variety (where the middle name is not necessarly placed in the middle), someone decides to store one's title... beacuse, well, the slot is there and they need to store this information
- In the 'ordered' variety, "John P. Smith", you might have "Murata Makoto". If you thought Makoto was the last name... you'd be wrong.
If you've ever looked into "quality of data" issues in huge databases, you know that these are two (out of thousands) typical problems -- but not problems in _adaptation_, in fact.
In short, unless a human is giving the 'ok' to an adapter's use, be it the application, framework, or component developer, then I'd expect wacko bugs.
A lot of the data quality problems in huge databases come exactly from humans -- data entry issues, form design issues, ... all the way to schema-design issues. I don't see why, discussing a data-quality problem, you'd think that having a human OK whatsoever would help wrt having a formalized rule (e.g. a database constraint) do it.
| This potentially opens the door to N-players scenarios for N>3, but, | like going from 3-tier to N-tier applications, that's not as huge a | jump as that from N==2 to N==3;-).
The problem with registries is that often times scope is needed; just beacuse my module wants to use this adaption path, doesn't mean your module will make the same choice. I avoided registries in the first pass of the draft to avoid this issue. So, if we are going to add registries, then namespaces for the registries need to also be discussed.
If _one_ registry of how to copy/serialize things is good enough for copy.py / copy_reg.py / pickle.py / ..., in the light of minimalism we should specify only one for PEP 246 too.
| So, are you willing to do that round of editing to PEP 246...? I'll | then to the NEXT one which will still undoubtedly be needed...
I could make a wack at it this weekend.
Great! I assume you have copies of all relevant mails since they all went around this mailing list, but if you need anything just holler, including asking me privately about anything that might be unclear or ambiguous or whatever -- I'll be around all weekend except Sunday night (italian time -- afternoon US time;-).
Thanks,
Alex
_______________________________________________ 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
