On 22 Jun 2004, at 20:42, Nick Stuart wrote:
Doesn't it make sense that a read-only sql field would still need a set method?
Let me clarify the situation I've got on my side...:
While we do have a single file responsible for db reading/writing of an object, there's a feed system in place that allows multiple possible representations based on parameters; each of the core 'feed' types is represented as a separate entry.
In combination with memcached, some of the fields in question have no setters; while they return values based on other queries, we do not bulk load that set of objects into the classes. So, for example, retrieving a list of Location or Category objects attached to a particular event is a delayed operation that takes place on the getter, and will pass through memcached before requesting it from the database to ensure that all servers get data from memcached before performing operations.
In this case, as in many other calculated fields, there is no setter - there is only a getter; in those situations, I would prefer not to implement dummy methods just to be able to use that information to return data.
So the interest for no-set is almost always a purely XML-focused activity on our side. On the DBO side, the reverse holds true; there may be methods which we don't want made public, because they reflect internal data that should not be directly usable by users of the object, who should use the prepared objects to which those values refer.
Make sense?
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
