> On Jul 7, 2017, at 3:03 AM, Aristedes Maniatis <a...@maniatis.org> wrote:
>
> * Does this make debugging memory with a profiler easier since it makes it
> simpler to identify field usage?
It makes regular debugging easier, as you no longer need to poke inside the
HashMap. Probably also memory profiling (fewer levels of nesting inside the
object make tracing retain paths simpler).
> * What is the impact on ROP?
None at the moment.
> * Would we want this to be an option for users or is there just no upside to
> the Map implementation?
In the past I thought readPropertyDirectly/writePropertyDirectly should be
faster with a Map. But as John and Nikita have demonstrated, this is no longer
true with Java 7 switch-based implementation. Remaining use cases for Map-based
objects in my mind are these:
1. Dynamic creation of OR mapping in runtime. I.e. generic objects.
2. A user code that relies on the Map structure to store unmapped properties
("CayenneDataObject.writePropertyDirectly" will not check the key validity).
Since both the old and the new objects will follow the same unchanged
framework/DataObject contract, we will preserve full backwards compatibility,
allowing users to stay with Map-based objects if they need to. Really it comes
down to a cgen temple selection. So I think in 4.1 we might do the following:
* Make the new cgen template the default (after rigorous testing).
* CayenneDataObject will stay around and will serve as a base for generic
objects and Map-based objects.
* The old cgen template will be available as an option for those who are
concerned with use case #2.
Andrus
