6.1 Proxyobject types

In principle the type of a proxy object is exactly the same as the type of the object it represents. It would be pretty impractical, however, if the current implementation demanded this, for at least the following reasons ^[10]:

• The proxy would have the same size as the real object had before initialization.
• As dynamic linking is not currently supported ^[11] the full code corresponding to the implementation of a pattern would have to be linked in with every client using the service provided by that pattern. Even with dynamic linking it would not be a feasible solution to link in server code in the client process.

The solution used in the current release of BETA distribution is to instantiate proxy objects as instances of the most specific pattern known to the client and that is declared in the shellEnvLib:attributes SLOT of shellEnv. This means that all operations to be used remotely must be declared in this SLOT, but the actual object may be an instance of any subpattern declared where it might be appropriate.

One unfortunate side effect of the implementation described above is that virtual entries are not supported. This has to do with the implementation of virtual dispatch in BETA, and is outside the scope of this manual. However, keep in mind that

Subpatterns of remoteable.entry are not allowed to be virtual.