Thought inc.

The Dynamic O/R Mapping Company

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Suggestions
CocoProxy and CocoProxyM
< Previous Thread  
Thread    Post New Thread     Post A Reply
Ed Ward

Registered: Feb 2002
Posts: 2

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.

02-21-2002 05:22 AM
Click Here to See the Profile for Ed Ward    Find more posts by Ed Ward        Edit/Delete Message    Reply w/Quote    IP: Logged

Registered: Apr 2001
Posts: 19

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...


02-22-2002 11:17 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread  

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.