With all due respect to all you far more OO-seasoned gentlemen than I, this isn't the response I expected. Here's what I was thinking:
- On a gut level, though I appreciate the value of an object that hides its internals completely and provides no access to them other than through its methods, it still felt strange to me that instance values, internal state, constants, etc, and methods were all dumped into the variables scope, and indistinguishable from them, except by diving through the properties array of the whole extends tree. Without doing that, even the object itself can't know what the data fields are, even internally, like for instance to iterate over them and ask each one if it's valid. To some extent, getMemento is related to, and my reaction to the need for, this kind of sometimes-necessary introspection. - If you google "coldfusion getMemento", you'll find multiple implementations. Perhaps these folks are all wrong-headed, but that reinforced my sense that this was a useful tool. - My first actual use case is to implement isDirty(). There are many ways to go about this, and I'm curious what your best practice is. What I was thinking was to populate the bean, then call setNotDirty(), which would call getMemento and save the result in an internal field. When isDirty() was called, you'd iterate over the fields in the object, comparing them to the saved values. This doesn't break encapsulation, or put raw un-object data out there for the whole world to see; it's internal. In this case, the answer to my actual question is that if you're going to compare the raw data rather the results of getters, getMemento should return the raw data; that's my initial inclination, without having built it. If you're going to compare getter results, getMemento needs to return them too. - The second use case I was thinking of is serialization, where the answer to my question seems to depend on where the data's going. If it ends up on another server in an object just like this one, you'd probably want getMemento to return the raw data, so it didn't run through getter processing both before serialization and when getters were called on the remote object. If it's headed for HTML rendering through a js templating engine, unless you want to duplicate the getter logic there, you probably want the getter values, with any formatting and other logic they have. Obviously, getMemento() isn't the same as serialize(), but it's arguable that serialize could call it in the generic default case. Maybe I'm just being OO-green to ask this question, but that's roughly what was on my mind. @Mike, I don't understand why you say you'd have to call getters to get anything other than the default values. The value of variables.myField will have changed if the object's setters were called with data that's different from the defaults; it's not necessary to call a getter to see that change. The difference is that getters may have their own logic, to format the raw data, combine it with other fields, etc, so the value in the variables scope may not be the same as what the getter returns. Dave ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:339304 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
