Richard, My primary reference for the Proxy Pattern is the classic "Design Patterns, Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley 1995). In describing how to implement the pattern the âGang of Four (or GOF)" advise âusing doesNotUnderstand in Smalltalkâ (p. 212). Furthermore, as to typing, they say that âProxy doesnât always have to know the type of real subjectâ (213). The GOF anticipated the problem with inlined selectors and caution that âa few special messages ... are handled directly by the virtual machine [and] do not cause the usual method look-upâ (p. 212). So, I think it is reasonable, in the context of a discussion of the Proxy Pattern, to suggest that the Proxy Pattern would be more effective with fewer inlined selectors. As to where the Proxy Pattern was developed, the GOF describe âKnown Usesâ including remote objects in NEXTSTEP (1994) and in Smalltalk (1987). In the remote object context, a Proxy has no need to know the type of the target, it just needs to know how to forward messages and return results. While there is typically a way to find out if something is a proxy or not (e.g., #â_isProxyâ) the beauty of the Proxy Pattern is that you donât have to rewrite the entire application and use something like #âapparentClassâ or #âapparentlyNilâ. Only the parts of the application that care if you have a proxy (which will typically not be the main domain code) need to look more deeply (with special selectors or reflection). It appears that you believe that a untyped proxy to a remote object is bad and that all the code in an application should be written to be aware of the possible âremotenessâ of certain objects. It is my understanding that a transparent untyped proxy to a remote object is well-accepted, extremely useful, and can be implemented reliably. I donât think I can contribute much more to the conversation than that so Iâll leave it there. Regards, James
On Mar 20, 2022, at 4:55 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
Never forget that the Proxy pattern was developed in the context of a TYPED programming language. So "Clients can't tell whether they work with a subject or its proxyâ means WITH REFERENCE TO A STATED PROTOCOL. Doing this in Ada or Java is fine, because you define an interface type, and that makes it safe. Here is a sentence from a typical description of the pattern: "Since the proxy implements the INTERFACE as the original class, it can be passed to any client that expects a real service object." Having a specified and *enforced* smallish interface prevents the maintenance issues that plague attempts to use this pattern in Smalltalk.
Remote objects and local objects have different semantics because remote messages and local messages have different semantics. Local messages cannot be lost, duplicated, or reordered, nor can communication with a local object drop out for no local reason. Version skew is a much bigger problem with distributed systems than local ones, so once again, it is proxying WITH REFERENCE TO A STATED PROTOCOL (and that not a large one!) that counts. There is no such thing as a 100% transparent remote proxy. So it is very useful to know what an object really is as well as what it pretends to be. That is, #class #apparentClass #isNil #apparentlyNil are *different*,
So the argument thus far is - a selector should not be inlined if it might need to be overridden - such as in an application of the Proxy pattern - but well-designed Proxies are such WITH REFERENCE TO STATED PROTOCOLS - meaning that selectors that are NOT in such protocols are fair game for inlining.