So I've been giving this a lot of thought over the last few days, and after all the dust has settled in my mind, here are my conclusions:
I'm more and more convinced that the design decision to create the classes and interfaces (and how they're structured) is sound. So much so that when I find some time, I plan to write up a knowledge base article discussing the topic. This article would serve as the "very long answer" addendum to the FAQ :) With respect to the naming conflict issue, a thought occurred to me that hasn't really been driven home before; and at least for me, it pushes me over the edge in favor of keeping the class names as they are. The thought is that Pivot provides adapter classes that let you take a JDK collection class and turn it into a Pivot collection class. And the great thing is this: those adapter classes don't have name conflicts! They're ListAdapter, MapAdapter, and SetAdapter. And these classes all delegate to their JDK counterparts under the hood. This line of thinking leads me to the fact that a developer doesn't have to use Pivot's ArrayList, HashMap, LinkedList, etc. at all if they don't want to... ever. The fact that the Pivot platform uses them under the hood is hidden from the application developer. So to the application developer who doesn't want name conflicts, the answer is: don't use the "native" classes if you don't want to - use the JDK collections, and wrap them in Pivot adapter classes where you have to. The fact is that the adapter classes are a very useful tool to those developers who would either rather, or have to, use JDK collections. That the adapter classes have hardly seen the light of day thus far is a both disservice to the platform and a tribute to the platform :) My 2c, -T On Thu, Aug 27, 2009 at 4:48 AM, Sandro Martini <[email protected]>wrote: > Hi to all, > for me it's the same: leave as is, or change the name to avoid > confusion (I'd like this a little more) ... but for new names please > don't ask to me :-) . > > But in any case it would be better to do it before the 1.3 release, or > we should wait for the next major release. > > Sandro >
