"Clark C. Evans" <cce at clarkevans.com> wrote in message news:mailman.986439487.17064.python-list at python.org... [snip] > > PEP 246 does not guarantee the symmetric behavior, which I > > think is required for going back and forth between object's > > interfaces. Although the PEP says that such behavior may be > > added. (See PEP's text) > > I'm just not a COM guru, I am (or, if I'm not, please don't let my employers know, as they remunerates me richly under the misapprehension that I am:-). > and I don't know the advantages or > disadvantages that come with this restriction. Thus, I left I do, and the semantic restrictions of "COM object identity" make a *lot* of sense... _in the context of COM's typical use-cases_, *particularly* the transparent use of objects (with proxies and marshaling) across different apartments/ processes/hosts. But these are *NOT* the typical use-cases for PEP 246! If such constraints were imposed, we'd be left with just about only the DIS-advantages, for very little gain. > it as an open issue for those who really understand this > deep stuff... I just want a standard way to adapt objects. Me, too; and, in that context, identity-constraints had better not be there. Otherwise, we end up with AT LEAST two ways to ask for adaptation-to-protocol -- one that is equivalent to COM's QueryInterface, WITH constraints, and one which is equivalent to COM's IServiceProvider interface, WITHOUT constraints (i.e., the latter is allowed to return an object with a different identity from that of the service-provider object -- in other words, one that lacks the ability to 'navigate' back to the original). Python's object-identity concept is the one expressed by the id() built-in function. There is no real need to superimpose _another_ sub-definition of "weak identity", objects with different id()'s which are partitioned into equivalence classes by the ability to 'navigate' between them by adaptation. In COM, you never "hold an object", only one or more of its interfaces, so the ONLY identity that is meaningful is the "equivalence" defined by the semantic identity-constraints. In Python, you DO "hold an object" -- that is the one and only job of any variable, item in a dictionary or list, attribute in an instance... the situation is really very different! > With this in mind, I actually like PEP 245 (Interfaces) as it is. > Adding a QueryInterface mechanism to it would just confuse issues. > Having an othognal adapt mechanism is better... besides, it could This also seems to me to be the case. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4