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.

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.