On Sep 22, 2011, at 2:53 AM, Aristedes Maniatis wrote: > I think we are all agreed that putting Object in the name of a method add no > value. But if we are thinking of designing a fluent query API [1] then > perhaps we should start there with a clean slate and devise a consistent > language. When that is done, it might be easier to bring the ideas back to > the existing API. Our users will not mind changing half a dozen method names > once, but will hate it if we do it one method at a time over the next 6 > releases.
Yes, I was also going for the minimal impact API changes until we have the full picture. > How do we go about documenting the next steps? We have lots of ideas, but no > consistent narrative through what we are wanting to do. Yes, we need a design for the API's that we've been talking about. I've intentionally avoided diving into this just yet, as I think 3.1 focus should be about DI and the new configuration, and the fluent API should go into the following release (3.2?). But that shouldn't stop us from having this discussion, sketching prototype or even building a separate module that we keep in SVN, but do not officially release. Maybe this will even motivate us to put 3.1 into Beta much sooner ;) Also there is a very big task that seems like a prerequisite for the new API changes (if we want to do it right that is) - merging EJBQL and SelectQuery into a single full featured object query that can be created either from String or via API. I thought we might approach this as building the 3rd type of query leaving EJBQL and SelectQuery as deprecated, but supported options. And that new query can be designed with generics and fluent API in mind. Andrus
