You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Todd Volkert <tv...@gmail.com> on 2009/08/26 21:15:14 UTC
Collection class/interface names
There's been talk of renaming our collection classes, because while they
serve technical value, they might cause confusion and frustration when used
in conjunction with the JDK collections in a large Java application. This
thread will serve as the place to brainstorm on what we could call them.
Note that many of the classes in the collections package aren't really under
scrutiny here, so let's start tightly focused on the really big and tough
ones:
ArrayList
HashMap
LinkedList
If changing the package name is not enough, then we have to come up with
different names for these classes. And yet their names hark back to the
early days of computer science - way before the JDK. One suggestion is to
prepend "P" or "Pivot" on to them, but at least to me, that seems like a
cop-out. Thus far, we've done a pretty good job avoiding words like
"Generic", "Default", "Abstract" as prepends to class names, as they tend to
not provide much value. The same goes for adding the package name in the
class name (com.foo.FooMap). Also, if we did this, then consistency would
seem to say that we should do the same for all classes in the package
(PivotEnumSet - yuck!). So where does that leave us? It seems that in
their current form, the fact that we created our own collections will be a
constant source of friction to our users and newbies, but (a) they do
provide real technical value, and (b) they're not easy to rename cleanly.
Thoughts?
-T
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
And let's not forget that there is no "collections" package in the
JDK. It's a minor point, I know, but that says to me that the package
name itself should not be in question.
On Aug 26, 2009, at 3:33 PM, Greg Brown wrote:
> Agreed on your take of the two camps.
>
> It is possible that #1 naturally resolves itself - as I said in my
> previous email, how often are you really going to need to use both
> Pivot and JDK collections in the same class file? Not often, I'd
> guess.
>
> Renaming "collections" to "model" may seem to address #2, but does
> it really, or is it just obfuscation? I think it is the latter. I
> also think it tends to make the nature of these classes less clear.
> As a developer, I would expect this package to be called
> "collections", not "model".
>
> G
>
> On Aug 26, 2009, at 3:22 PM, Todd Volkert wrote:
>
>> Another thought occurred to me after sending this email. The
>> contentious
>> nature of these collections can be split into two sub-camps:
>>
>> 1. "Now I have to deal with class name conflicts in my application
>> (java.util.HashMap and org.apache.pivot.collections.HashMap). Grrr."
>> 2. "Why did you reinvent something that already existed?"
>>
>> To me, renaming the *package* might satisfy #2 but not #1. For
>> instance,
>> if, for the sake of argument, we called the package
>> org.apache.pivot.model,
>> then maybe the nature of why we didn't use the JDK classes will be
>> more
>> immediately apparent. After all, people didn't scream at Sun for
>> creating
>> javax.swing.ListModel.
>>
>> I'm not saying that "model" is the best term (it was off the cuff),
>> but the
>> point is that we might be able to satisfy one camp of complains
>> with a
>> package rename.
>>
>> As for complaint #1, that's tougher and more the subject of the
>> opening
>> email in this thread.
>>
>> -T
>>
>> On Wed, Aug 26, 2009 at 3:15 PM, Todd Volkert <tv...@gmail.com>
>> wrote:
>>
>>> There's been talk of renaming our collection classes, because
>>> while they
>>> serve technical value, they might cause confusion and frustration
>>> when used
>>> in conjunction with the JDK collections in a large Java
>>> application. This
>>> thread will serve as the place to brainstorm on what we could call
>>> them.
>>> Note that many of the classes in the collections package aren't
>>> really under
>>> scrutiny here, so let's start tightly focused on the really big
>>> and tough
>>> ones:
>>>
>>> ArrayList
>>> HashMap
>>> LinkedList
>>>
>>> If changing the package name is not enough, then we have to come
>>> up with
>>> different names for these classes. And yet their names hark back
>>> to the
>>> early days of computer science - way before the JDK. One
>>> suggestion is to
>>> prepend "P" or "Pivot" on to them, but at least to me, that seems
>>> like a
>>> cop-out. Thus far, we've done a pretty good job avoiding words like
>>> "Generic", "Default", "Abstract" as prepends to class names, as
>>> they tend to
>>> not provide much value. The same goes for adding the package name
>>> in the
>>> class name (com.foo.FooMap). Also, if we did this, then
>>> consistency would
>>> seem to say that we should do the same for all classes in the
>>> package
>>> (PivotEnumSet - yuck!). So where does that leave us? It seems
>>> that in
>>> their current form, the fact that we created our own collections
>>> will be a
>>> constant source of friction to our users and newbies, but (a) they
>>> do
>>> provide real technical value, and (b) they're not easy to rename
>>> cleanly.
>>>
>>> Thoughts?
>>> -T
>>>
>
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
Agreed on your take of the two camps.
It is possible that #1 naturally resolves itself - as I said in my
previous email, how often are you really going to need to use both
Pivot and JDK collections in the same class file? Not often, I'd guess.
Renaming "collections" to "model" may seem to address #2, but does it
really, or is it just obfuscation? I think it is the latter. I also
think it tends to make the nature of these classes less clear. As a
developer, I would expect this package to be called "collections", not
"model".
G
On Aug 26, 2009, at 3:22 PM, Todd Volkert wrote:
> Another thought occurred to me after sending this email. The
> contentious
> nature of these collections can be split into two sub-camps:
>
> 1. "Now I have to deal with class name conflicts in my application
> (java.util.HashMap and org.apache.pivot.collections.HashMap). Grrr."
> 2. "Why did you reinvent something that already existed?"
>
> To me, renaming the *package* might satisfy #2 but not #1. For
> instance,
> if, for the sake of argument, we called the package
> org.apache.pivot.model,
> then maybe the nature of why we didn't use the JDK classes will be
> more
> immediately apparent. After all, people didn't scream at Sun for
> creating
> javax.swing.ListModel.
>
> I'm not saying that "model" is the best term (it was off the cuff),
> but the
> point is that we might be able to satisfy one camp of complains with a
> package rename.
>
> As for complaint #1, that's tougher and more the subject of the
> opening
> email in this thread.
>
> -T
>
> On Wed, Aug 26, 2009 at 3:15 PM, Todd Volkert <tv...@gmail.com>
> wrote:
>
>> There's been talk of renaming our collection classes, because while
>> they
>> serve technical value, they might cause confusion and frustration
>> when used
>> in conjunction with the JDK collections in a large Java
>> application. This
>> thread will serve as the place to brainstorm on what we could call
>> them.
>> Note that many of the classes in the collections package aren't
>> really under
>> scrutiny here, so let's start tightly focused on the really big and
>> tough
>> ones:
>>
>> ArrayList
>> HashMap
>> LinkedList
>>
>> If changing the package name is not enough, then we have to come up
>> with
>> different names for these classes. And yet their names hark back
>> to the
>> early days of computer science - way before the JDK. One
>> suggestion is to
>> prepend "P" or "Pivot" on to them, but at least to me, that seems
>> like a
>> cop-out. Thus far, we've done a pretty good job avoiding words like
>> "Generic", "Default", "Abstract" as prepends to class names, as
>> they tend to
>> not provide much value. The same goes for adding the package name
>> in the
>> class name (com.foo.FooMap). Also, if we did this, then
>> consistency would
>> seem to say that we should do the same for all classes in the package
>> (PivotEnumSet - yuck!). So where does that leave us? It seems
>> that in
>> their current form, the fact that we created our own collections
>> will be a
>> constant source of friction to our users and newbies, but (a) they do
>> provide real technical value, and (b) they're not easy to rename
>> cleanly.
>>
>> Thoughts?
>> -T
>>
Re: Collection class/interface names
Posted by Todd Volkert <tv...@gmail.com>.
Another thought occurred to me after sending this email. The contentious
nature of these collections can be split into two sub-camps:
1. "Now I have to deal with class name conflicts in my application
(java.util.HashMap and org.apache.pivot.collections.HashMap). Grrr."
2. "Why did you reinvent something that already existed?"
To me, renaming the *package* might satisfy #2 but not #1. For instance,
if, for the sake of argument, we called the package org.apache.pivot.model,
then maybe the nature of why we didn't use the JDK classes will be more
immediately apparent. After all, people didn't scream at Sun for creating
javax.swing.ListModel.
I'm not saying that "model" is the best term (it was off the cuff), but the
point is that we might be able to satisfy one camp of complains with a
package rename.
As for complaint #1, that's tougher and more the subject of the opening
email in this thread.
-T
On Wed, Aug 26, 2009 at 3:15 PM, Todd Volkert <tv...@gmail.com> wrote:
> There's been talk of renaming our collection classes, because while they
> serve technical value, they might cause confusion and frustration when used
> in conjunction with the JDK collections in a large Java application. This
> thread will serve as the place to brainstorm on what we could call them.
> Note that many of the classes in the collections package aren't really under
> scrutiny here, so let's start tightly focused on the really big and tough
> ones:
>
> ArrayList
> HashMap
> LinkedList
>
> If changing the package name is not enough, then we have to come up with
> different names for these classes. And yet their names hark back to the
> early days of computer science - way before the JDK. One suggestion is to
> prepend "P" or "Pivot" on to them, but at least to me, that seems like a
> cop-out. Thus far, we've done a pretty good job avoiding words like
> "Generic", "Default", "Abstract" as prepends to class names, as they tend to
> not provide much value. The same goes for adding the package name in the
> class name (com.foo.FooMap). Also, if we did this, then consistency would
> seem to say that we should do the same for all classes in the package
> (PivotEnumSet - yuck!). So where does that leave us? It seems that in
> their current form, the fact that we created our own collections will be a
> constant source of friction to our users and newbies, but (a) they do
> provide real technical value, and (b) they're not easy to rename cleanly.
>
> Thoughts?
> -T
>
Re: Collection class/interface names
Posted by Noel Grandin <no...@gmail.com>.
Greg Brown wrote:
> Yes, it might be a pain to combine a Pivot ArrayList and a JDK
> ArrayList in the same source file, but realistically, that's not
> likely to happen very often. If you are writing a Pivot app, you are
> most likely going to be using Pivot collections (at least, in your
> Pivot code). You may have some server-side code that uses JDK
> collections, but, in general, that shouldn't conflict with what you
> are doing in the UI. On the other hand, if you are using Pivot's
> QueryServlet class, you may find that you want to use Pivot's
> collections on the server as well.
It's not really a case of combining them in the same file. It's that in
a large Pivot project, by necessity,
(a) you are going to have lots of code using both pivot's ArrayList and
java's ArrayList
(b) you are going to be staring at code that you did not write
If you open some random file and starting looking at code, it's very
annoying to suddenly discover that what you thought was a Pivot
ArrayList is, in fact, a Java ArrayList, or vice versa.
While I don't generally like assigning prefixes to classnames, I have
found it to be a very useful means of reducing the cognitive load
required when scanning through our codebase.
-- Noel.
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
> I just wanted to provide some additional context. I think it goes
> without question that we will get additional skepticism, but I would
> like to be able to say that we have tried our best to acknowledge
> the questions and concerns that have been raised thus far.
From all perspectives, that is - not just Todd's and my own...
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
I just wanted to provide some additional context. I think it goes
without question that we will get additional skepticism, but I would
like to be able to say that we have tried our best to acknowledge the
questions and concerns that have been raised thus far.
On Aug 29, 2009, at 2:05 PM, Niclas Hedhman wrote:
> Perhaps you misunderstood me... decision is made... time will tell
> if you
> will get a lot of scepticism or not, and whether that will be a
> thorn in the
> toe, stone on the shoe, hair in the eye, or not...
>
> Cheers
> Niclas
>
> On Aug 29, 2009 8:17 PM, "Greg Brown" <gk...@mac.com> wrote:
>
> Here's why I described this as the "right" approach. The other day,
> when we
> were discussing this, it occurred to me that one way to address
> Ralph's and
> Noel's concerns might be to simply eliminate the Pivot-native
> collection
> classes (ArrayList, LinkedList, etc.) and move the adapter classes
> (ListAdapter, MapAdapter, and SetAdapter) up to
> org.apache.pivot.collections
> proper. The adapter classes are clearly named, so this wouldn't seem
> like an
> "artificial" or "contrived" design, and they allow developers to
> both take
> advantage of Pivot's collection interfaces and continue using the
> existing,
> well-known JDK collection classes.
>
> However, as Todd and I have reiterated, we think there are valid
> reasons for
> continuing to support Pivot's native collection implementations. It
> seemed
> to us that, if we leave the collections as they are, but simply draw
> more
> attention to the adapter classes, we might be able to address
> everyone's
> concerns. If you think that naming collisions, performance, or
> anything else
> related to the use of Pivot-native collections might be an issue,
> you are
> free to use the adapters. Otherwise, you can continue to use the
> Pivot-native versions.
>
> This way, we don't need to sacrifice one in favor of the other - both
> options are available, and can be applied as appropriate based on an
> individual developer's needs and tastes.
>
> G
>
> On Aug 29, 2009, at 2:51 AM, Niclas Hedhman wrote: > On Fri, Aug 28,
> 2009 at
> 8:01 PM, Greg Brown...
Re: Collection class/interface names
Posted by Niclas Hedhman <ni...@hedhman.org>.
Perhaps you misunderstood me... decision is made... time will tell if you
will get a lot of scepticism or not, and whether that will be a thorn in the
toe, stone on the shoe, hair in the eye, or not...
Cheers
Niclas
On Aug 29, 2009 8:17 PM, "Greg Brown" <gk...@mac.com> wrote:
Here's why I described this as the "right" approach. The other day, when we
were discussing this, it occurred to me that one way to address Ralph's and
Noel's concerns might be to simply eliminate the Pivot-native collection
classes (ArrayList, LinkedList, etc.) and move the adapter classes
(ListAdapter, MapAdapter, and SetAdapter) up to org.apache.pivot.collections
proper. The adapter classes are clearly named, so this wouldn't seem like an
"artificial" or "contrived" design, and they allow developers to both take
advantage of Pivot's collection interfaces and continue using the existing,
well-known JDK collection classes.
However, as Todd and I have reiterated, we think there are valid reasons for
continuing to support Pivot's native collection implementations. It seemed
to us that, if we leave the collections as they are, but simply draw more
attention to the adapter classes, we might be able to address everyone's
concerns. If you think that naming collisions, performance, or anything else
related to the use of Pivot-native collections might be an issue, you are
free to use the adapters. Otherwise, you can continue to use the
Pivot-native versions.
This way, we don't need to sacrifice one in favor of the other - both
options are available, and can be applied as appropriate based on an
individual developer's needs and tastes.
G
On Aug 29, 2009, at 2:51 AM, Niclas Hedhman wrote: > On Fri, Aug 28, 2009 at
8:01 PM, Greg Brown...
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
Here's why I described this as the "right" approach. The other day,
when we were discussing this, it occurred to me that one way to
address Ralph's and Noel's concerns might be to simply eliminate the
Pivot-native collection classes (ArrayList, LinkedList, etc.) and move
the adapter classes (ListAdapter, MapAdapter, and SetAdapter) up to
org.apache.pivot.collections proper. The adapter classes are clearly
named, so this wouldn't seem like an "artificial" or "contrived"
design, and they allow developers to both take advantage of Pivot's
collection interfaces and continue using the existing, well-known JDK
collection classes.
However, as Todd and I have reiterated, we think there are valid
reasons for continuing to support Pivot's native collection
implementations. It seemed to us that, if we leave the collections as
they are, but simply draw more attention to the adapter classes, we
might be able to address everyone's concerns. If you think that naming
collisions, performance, or anything else related to the use of Pivot-
native collections might be an issue, you are free to use the
adapters. Otherwise, you can continue to use the Pivot-native versions.
This way, we don't need to sacrifice one in favor of the other - both
options are available, and can be applied as appropriate based on an
individual developer's needs and tastes.
G
On Aug 29, 2009, at 2:51 AM, Niclas Hedhman wrote:
> On Fri, Aug 28, 2009 at 8:01 PM, Greg Brown<gk...@mac.com> wrote:
>
>> I think this is the right approach.
>
> Time will tell if this is the right approach, and my take is that next
> time either one of you get frustrated over someone asking "Why?"
> again, I call it "not smart" and a failure to understand how other
> people perceive your work... ;-)
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
Re: Collection class/interface names
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Aug 28, 2009 at 8:01 PM, Greg Brown<gk...@mac.com> wrote:
> I think this is the right approach.
Time will tell if this is the right approach, and my take is that next
time either one of you get frustrated over someone asking "Why?"
again, I call it "not smart" and a failure to understand how other
people perceive your work... ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Collection class/interface names
Posted by Sandro Martini <sa...@gmail.com>.
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
Re: Collection class/interface names
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Aug 27, 2009 at 4:12 PM, Jorg Heymans<jo...@gmail.com> wrote:
> Most developers
> don't even care about these collection classes,
They have to. They are part of the programmatic interface to Pivot...
I agree it is not THAT important, yet I also think that it is not THAT
hard to choose non-conflicting names.
Map -> NotifyingMap, MappedModel, ModelMap....
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Collection class/interface names
Posted by Jorg Heymans <jo...@gmail.com>.
On Wed, Aug 26, 2009 at 9:28 PM, Greg Brown<gk...@mac.com> wrote:
> My vote (in case some of you are not aware of it) is to leave the names
> as-is. As Todd says, Sun didn't invent these terms - they have been around
> for a long time. Calling these classes anything other than what they are
> seems artificial (and confusing).
<delurk>
In Eclipse, when i do ctrl-shift-t and then type List i get
List - antlr.collections
List - com.sun.xml.bind.v2.schemagen.xmlschema
List - groovyjarjar.antlr.collections
List - java.awt
List - java.util
When I type Map i get
Map - java.util
Map - javax.swing.text.html
Map - org.hibernate.mapping
Now if this would really bother me (which it doesn't) i would go to
settings-java-appearance-type filters and exlude the packages i don't
want to see in autocompletion. I'm sure intellij has a similar option.
Looking at koders.com, there are *many* other projects that use these
terms as well
Map.java -> http://www.koders.com/?s=file%3aMap.java&la=Java&li=*
ArrayList.java ->
http://www.koders.com/default.aspx?s=file%3AArrayList.java&btn=&la=Java&li=*
LinkedList.java ->
http://www.koders.com/default.aspx?s=file%3ALinkedList.java&btn=&la=Java&li=*
So what is the big deal here ? If this were commons-collections then i
would understand the energy being spent on the discussion, but Pivot
is a state of the art RIA framework for god's sake :-) Most developers
don't even care about these collection classes, they just want to
deliver a kick-ass RIA app to their customers, something which Pivot
claims to do very well. The collection classes are neither Pivot's
main drawback nor its biggest feature, so focus energy on the part
that your users will really care about.
</delurk>
Jorg
Re: Collection class/interface names
Posted by Greg Brown <gk...@mac.com>.
My vote (in case some of you are not aware of it) is to leave the
names as-is. As Todd says, Sun didn't invent these terms - they have
been around for a long time. Calling these classes anything other than
what they are seems artificial (and confusing).
Yes, it might be a pain to combine a Pivot ArrayList and a JDK
ArrayList in the same source file, but realistically, that's not
likely to happen very often. If you are writing a Pivot app, you are
most likely going to be using Pivot collections (at least, in your
Pivot code). You may have some server-side code that uses JDK
collections, but, in general, that shouldn't conflict with what you
are doing in the UI. On the other hand, if you are using Pivot's
QueryServlet class, you may find that you want to use Pivot's
collections on the server as well.
We have considered various alternatives in the past, and nothing
seemed to fit better than what we have right now. However, if you do
have a suggestion as to how we might cleanly resolve this, please let
us know.
Thanks,
Greg
On Aug 26, 2009, at 3:15 PM, Todd Volkert wrote:
> There's been talk of renaming our collection classes, because while
> they
> serve technical value, they might cause confusion and frustration
> when used
> in conjunction with the JDK collections in a large Java
> application. This
> thread will serve as the place to brainstorm on what we could call
> them.
> Note that many of the classes in the collections package aren't
> really under
> scrutiny here, so let's start tightly focused on the really big and
> tough
> ones:
>
> ArrayList
> HashMap
> LinkedList
>
> If changing the package name is not enough, then we have to come up
> with
> different names for these classes. And yet their names hark back to
> the
> early days of computer science - way before the JDK. One suggestion
> is to
> prepend "P" or "Pivot" on to them, but at least to me, that seems
> like a
> cop-out. Thus far, we've done a pretty good job avoiding words like
> "Generic", "Default", "Abstract" as prepends to class names, as they
> tend to
> not provide much value. The same goes for adding the package name
> in the
> class name (com.foo.FooMap). Also, if we did this, then consistency
> would
> seem to say that we should do the same for all classes in the package
> (PivotEnumSet - yuck!). So where does that leave us? It seems that
> in
> their current form, the fact that we created our own collections
> will be a
> constant source of friction to our users and newbies, but (a) they do
> provide real technical value, and (b) they're not easy to rename
> cleanly.
>
> Thoughts?
> -T