Why are there two classes for proxying classes using reflection? Admittedly CocoProxy uses public accessible attributes and CocoProxyM uses getter/setter property methods but I think it would be better if there was a single transparant persistence proxy class.

CocoProxyM is coupled to CocoProxy anyway via the usePublicFields(boolean) method, which causes the class to attempt to populate the proxied instance through the use of public attributes via an instance of CocoProxy.

I believe version 4 of CocoBase automatically wraps objects that don't implement either CBProp or CBDrop in an instance of CocoProxyM. Couple this with the fact that public attributes are generally considered bad design, I don't think the use of CocoProxy is a good idea. ie. I will always use CocoProxyM.

Will you be deprecating CocoProxy at some point? Personally I think the name CocoProxyM is a bit weird, and CocoProxy should be made backwardly compatible with CocoProxyM and CocoProxyM should be deprecated.

You ask why there are two classes for Proxying.

1) Because of performance.

2) Because customers usually want the choice.

3) Because of EJB programming requirements.

4) The coupling of CocoProxyM to CocoProxy is disabled by
default, and is only enabled under special circumstances.

5) CocoProxy must be used for EJB primary keys which do not
have (nor legally should have) public accessor methods.

Thanks for your suggestion of deprecating CocoProxy, but that
wouldn't be appropriate or a good idea because of the various
platforms and customer requirements we support...

There are some very valid reasons for using only method
reflections, many of the compatibility reasons... Otherwise
our engineers would have done this a long time ago - but
thanks for your prompting...

THOUGHT Support