On 2005 Jan 12, at 17:40, Phillip J. Eby wrote:
At 04:36 PM 1/12/05 +0100, Alex Martelli wrote:I already know -- you told us so -- that if I had transitivity as you wish it (uncontrollable, unstoppable, always-on) I could not any more write and register a perfectly reasonable adapter which fills in with a NULL an optional field in the adapted-to interface, without facing undetected degradation of information quality by that adapter being invisibly, uncontrollably chained up with another -- no error message, no nothing, no way to stop this -- just because a direct adapter wasn't correctly written and registered.
But why would you *want* to do this, instead of just explicitly converting? That's what I don't understand. If I were writing such a converter, I wouldn't want to register it for ANY implicit conversion, even if it was non-transitive!
Say I have an SQL DB with a table such as:
CREATE TABLE fullname (
first VARCHAR(50) NOT NULL,
middle VARCHAR(50),
last VARCHAR(50) NOT NULL,
-- snipped other information fields
)Now, I need to record a lot of names of people, which I get from a vast variety of sources, so they come in as different types. No problem: I'll just adapt each person-holding type to an interface which offers first, middle and last names (as well as other information fields, here snipped), using None to mean I don't know the middle name for a given person (that's what NULL means, after all: "information unknown" or the like; the fact that fullname.middle is allowed to be NULL indicates that, while it's of course BETTER to have that information, it's not a semantic violation if that information just can't be obtained nohow).
All of my types which hold info on people can at least supply first and last names; some but not all can supply middle names. Fine, no problem: I can adapt them all with suitable adapters anyway, noninvasively, without having to typecheck, typeswitch, or any other horror. Ah, the magic of adaptation! So, I define an interface -- say with arbitrary syntax:
interface IFullname:
first: str
middle: str or None
last: str
# snipped other information fieldsand my function to write a data record is just:
def writeFullname(person: IFullname):
# do the writingSo, I have another interface in a similar vein, perhaps to map to/from some LDAP and similar servers which provide a slightly different set of info fields:
interface IPerson:
firstName: str
lastName: str
userid: str
# snipped other stuffI have some data about people coming in from LDAP and the like, which I want to record in that SQL DB -- the incoming data is held in types that implement IPerson, so I write an adapter IPerson -> IFullname for the purpose.
If the datatypes are immutable, conversion is as good as adaptation here, as I mentioned ever since the first mail in which I sketched this case, many megabytes back. But adaptation I can get automatically WITHOUT typechecking on what exactly is the concrete type I'm having to write (send to LDAP, whatver) this time -- a crucial advantage of adaptation, as you mention in the PyProtocols docs. Besides, maybe in some cases some of those attributes are in fact properties that get computed at runtime, fetched from a slow link if and only if they're first required, whatever, or even, very simply, some datatype is mutable and I need to ensure I'm dealing with the current state of the object/record. So, I'm not sure why you appear to argue for conversion against adaptation, or explicit typechecking against the avoidance thereof which is such a big part of adapt's role in life.
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
