Joe DeVivo wrote: > Please correct me if I'm wrong, I'm just sort of restating your > proposal to make sure I understand it and how it fits in the app. What > you're suggesting here is not to abandon the PropertyList, but to > encapsulate it by replacing get(name) with getName(). Then we lose the > dependency on the HashMap implementation of PropertyList, and we
Yes, or any other implementation-specific structure. Now, I think it may make sense to abandon PropertyList, but that is a separate question. All I am really trying to do here is lay the groundwork for someone to come along & make the Properties more efficient. > prevent people from thinking they'll get a property back from a FObj > that doesn't support that property. This would at least be possible under the proposal, but wouldn't necessarily be so. One possible implementation is to simply put a "get" method for each property in FObj and have it use the current system to retrieve the value from the PropertyList. This approach wouldn't address the issue you raise, unless an overridden method that returns a "not supported" value were created in the subclass. Victor Mote
