Dave
Merrill wrote:
What do you think about generic setValue(value_name, value, expected_type)
and getValue(value_name) methods?
A bean explicitly maps out it's purpose. Using a generic type bean
moves the uniqueness as well as the responsibility of that object into the
calling code. A generic bean is no longer a discrete object and no
longer represents the true nature of your mode. If I received legacy
code like this, I would have to look through thousands of lines of code just
to see what what this generic bean is doing instead of firing up the cfc
explorer to see what it actually does.
Just to be clear here, I'm *not* suggesting what I'd call a "generic
bean", one without an explicit data structure. The only things I'm suggesting
could be generic were non-exceptional setters and getters, where nothing
happens but simple setting and getting, maybe argument
type-checking.
Given that, I don't see how any research "through thousands of lines of
code" would be required to understand the function of the bean. It
contains *explicitly defined* data, and its public data members have
getters and setters, end of story. This is only about how those getters and
setters are implemented, doing it in a generic reusable
way.
----------------
CHANGE OF THINKING... As I wrote the above, I saw the problem with
generic getters and setters. It's evil for calling code to know which data has
an exceptional getter or setter. That says that all get/set methods,
exceptional or not, have to call the same generic get and set methods, and
those "generic" methods have to react to which data member they're addressing,
calling member-specific code for exceptional ones. I don't
like that at all.
Apologies to everyone who was way ahead of me on this; just had to
think it through.
Dave Merrill
----------------------------------------------------------