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.
