- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Ctrie naming
Thu, 2012-02-16, 16:16
Hi,
is it possible to change the class name of Ctrie to something more in line with the style guide out there?
Having "ConcurrentHashMap" in Java I think "ConcurrentTrie" is a reasonable choice. Imho it is very dangerous to not
follow the standard naming without a very good reason, because it
serves as precedent and excuse for users to ignore naming conventions in
their own code.
Scala Style guide:
Classes should be named in the camelCase style with the very first letter of the name capitalized [...] This mimics the Java naming convention for classes.
http://docs.scala-lang.org/style/naming-conventions.html#classestraits
Java naming conventions:
Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#585858
Thanks!
Simon
Thu, 2012-02-16, 17:01
#2
Re: Ctrie naming
On 2/16/12 4:21 PM, Paul Phillips wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
CAEaELhQ_GzwLqO+5S1fedT2naAUj75cf6qArvO-1zQOEGNq_sw [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Feb 16, 2012 at 7:16 AM, Simon Ochsenreither <simon [dot] ochsenreither [at] googlemail [dot] com" rel="nofollow">simon.ochsenreither@googlemail.com> wrote:
You're absolutely right, Ctrie is less than self-explanatory. Maybe it would be defensible if it were in a package called "concurrent" or otherwise explanatory, but it's in scala.collection.mutable.is it possible to change the class name of Ctrie to something more in line with the style guide out there?
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 17:21
#3
Re: Ctrie naming
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
Thu, 2012-02-16, 17:31
#4
Re: Ctrie naming
On 2/16/12 5:18 PM, Paul Phillips wrote:
I would be in favour of this aliases package idea.
CAEaELhTg3eYAofMjAL1M2Vf1d7rsLTzRm4eM58EiE5oSMGicag [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:01
#5
Re: Ctrie naming
What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:11
#6
Re: Ctrie naming
Not bad either, imo. It would be an extra subpackage in the
collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:
On 2/16/12 5:56 PM, Rex Kerr wrote:
CAP_xLa15+OM8iAGZm33dxYGkVzjANVDd_Dz0TFaD23EcLw+rgA [at] mail [dot] gmail [dot] com" type="cite"> What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" target="_blank" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:21
#7
Re: Ctrie naming
But to emphasize proper naming schemes, I would then call it
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:
4F3D369C [dot] 7080306 [at] epfl [dot] ch" type="cite"> Not bad either, imo. It would be an extra subpackage in the collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:CAP_xLa15+OM8iAGZm33dxYGkVzjANVDd_Dz0TFaD23EcLw+rgA [at] mail [dot] gmail [dot] com" type="cite"> What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" target="_blank" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:31
#8
Re: Ctrie naming
Agreed. Though if it is the _only_ concurrent thing in the mutable collections library, and it is the _only_ mutable tree map, there's an argument for just making it mutable.TreeMap and explaining in the docs that it's concurrency-friendly. The extra package would only be needed to advertise that it existed.
--Rex
On Thu, Feb 16, 2012 at 12:12 PM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
--Rex
On Thu, Feb 16, 2012 at 12:12 PM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
But to emphasize proper naming schemes, I would then call it
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:Not bad either, imo. It would be an extra subpackage in the collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:41
#9
Re: Ctrie naming
Not sure if the TreeMap is a good name - in most languages `Tree`
implies there is an order between the elements in the collection -
with Ctries this is not the case - they are just maps in the broader
sense.
Also, if we put them directly in the `mutable` package, the docs might help, but ideally the name should communicate the fact they are concurrent, imo.
On 2/16/12 6:24 PM, Rex Kerr wrote:
Also, if we put them directly in the `mutable` package, the docs might help, but ideally the name should communicate the fact they are concurrent, imo.
On 2/16/12 6:24 PM, Rex Kerr wrote:
CAP_xLa3c38-GJS5L0eYJ1XjGs+jD1f0kt-DhRWdzf1KLcBykSg [at] mail [dot] gmail [dot] com" type="cite">Agreed. Though if it is the _only_ concurrent thing in the mutable collections library, and it is the _only_ mutable tree map, there's an argument for just making it mutable.TreeMap and explaining in the docs that it's concurrency-friendly. The extra package would only be needed to advertise that it existed.
--Rex
On Thu, Feb 16, 2012 at 12:12 PM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
But to emphasize proper naming schemes, I would then call it
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:Not bad either, imo. It would be an extra subpackage in the collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" target="_blank" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" target="_blank" rel="nofollow">aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 18:51
#10
Re: Ctrie naming
ConcurrentTrieMap?
On Feb 16, 2012 6:30 PM, "Aleksandar Prokopec" <aleksandar.prokopec@gmail.com> wrote:Not sure if the TreeMap is a good name - in most languages `Tree` implies there is an order between the elements in the collection - with Ctries this is not the case - they are just maps in the broader sense.
Also, if we put them directly in the `mutable` package, the docs might help, but ideally the name should communicate the fact they are concurrent, imo.
On 2/16/12 6:24 PM, Rex Kerr wrote:Agreed. Though if it is the _only_ concurrent thing in the mutable collections library, and it is the _only_ mutable tree map, there's an argument for just making it mutable.TreeMap and explaining in the docs that it's concurrency-friendly. The extra package would only be needed to advertise that it existed.
--Rex
On Thu, Feb 16, 2012 at 12:12 PM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
But to emphasize proper naming schemes, I would then call it
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:Not bad either, imo. It would be an extra subpackage in the collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 19:01
#11
Re: Ctrie naming
On Thu, Feb 16, 2012 at 14:18, Paul Phillips wrote:
>
>
> On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec
> wrote:
>>
>> I agree that we should have a self-explanatory name, and I'm open to
>> ideas.
>> I would however prefer something which is easy relatively short and easy
>> to write.
>>
>> ConcurrentHashMap seems long to me.
>
>
> I too am easily annoyed by long names, but I think that's solving the
> problem at the wrong level. Give it a self-explanatory canonical name, and
> let's make a package with a standard set of aliases for lovers of terseness.
> Otherwise this tug of war goes on forever and nobody is ever happy (the
> same name cannot satisfy both camps, but a hybrid is unlikely to satisfy
> EITHER camp.)
The recently added rewrite of RedBlack does this:
class RedBlack ...
import ....{RedBlack => RB}
And then use RB elsewhere. I have noticed that ScalaDoc doesn't undo
such import renames, but, other than that, would there be any
problems?
Thu, 2012-02-16, 19:11
#12
Re: Ctrie naming
Sorry--I kept typing "tree" when I was thinking "trie". TrieMap. I guess my only real point is that putting it in concurrent is better than prepending Concurrent, just like putting collections in mutable is better than prepending Mutable. For Par, I understand the reasoning; the distinctions in usage are actually quite important. But I'm glad that we don't have to type out SequentialMutableDoubleLinkedList.
--Rex
On Thu, Feb 16, 2012 at 12:30 PM, Aleksandar Prokopec <aleksandar.prokopec@gmail.com> wrote:
--Rex
On Thu, Feb 16, 2012 at 12:30 PM, Aleksandar Prokopec <aleksandar.prokopec@gmail.com> wrote:
Not sure if the TreeMap is a good name - in most languages `Tree` implies there is an order between the elements in the collection - with Ctries this is not the case - they are just maps in the broader sense.
Also, if we put them directly in the `mutable` package, the docs might help, but ideally the name should communicate the fact they are concurrent, imo.
On 2/16/12 6:24 PM, Rex Kerr wrote:Agreed. Though if it is the _only_ concurrent thing in the mutable collections library, and it is the _only_ mutable tree map, there's an argument for just making it mutable.TreeMap and explaining in the docs that it's concurrency-friendly. The extra package would only be needed to advertise that it existed.
--Rex
On Thu, Feb 16, 2012 at 12:12 PM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
But to emphasize proper naming schemes, I would then call it
concurrent.TrieMap
or with the import, just:
TrieMap
On 2/16/12 6:02 PM, Aleksandar Prokopec wrote:Not bad either, imo. It would be an extra subpackage in the collections package, but I see no problem with that.
On 2/16/12 5:56 PM, Rex Kerr wrote:What's wrong with dropping the whole thing in mutable.concurrent (as Trie) so people who like length can
concurrent.Trie
and those who like brevity can
Trie
?
--Rex
On Thu, Feb 16, 2012 at 11:23 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
On 2/16/12 5:18 PM, Paul Phillips wrote:
On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.ch> wrote:
I agree that we should have a self-explanatory name, and I'm open to ideas.
I would however prefer something which is easy relatively short and easy to write.
ConcurrentHashMap seems long to me.
I too am easily annoyed by long names, but I think that's solving the problem at the wrong level. Give it a self-explanatory canonical name, and let's make a package with a standard set of aliases for lovers of terseness. Otherwise this tug of war goes on forever and nobody is ever happy (the same name cannot satisfy both camps, but a hybrid is unlikely to satisfy EITHER camp.)
I would be in favour of this aliases package idea.
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
-- Aleksandar Prokopec, Doctoral Assistant LAMP, IC, EPFL http://people.epfl.ch/aleksandar.prokopec
Thu, 2012-02-16, 19:31
#13
Re: Ctrie naming
ConcurrentTrieMap sounds good. This would make it especially easy to people coming from Java, because they already know “ConcurrentHashMap”.
People who want a shorter name can just import it by a name they like, but I think the defaults should be sane and follow the rules.
I'm not sure about creating a whole new package for basically one class...
People who want a shorter name can just import it by a name they like, but I think the defaults should be sane and follow the rules.
I'm not sure about creating a whole new package for basically one class...
Thu, 2012-02-16, 20:11
#14
Re: Ctrie naming
On Thu, Feb 16, 2012 at 9:56 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
import ....{RedBlack => RB}
And then use RB elsewhere. I have noticed that ScalaDoc doesn't undo
such import renames, but, other than that, would there be any
problems?
This forces you to issue the import in every file where you use it.
You might think, OK, I will define aliases at the package level and all will be well. Then you will run into this, one of my least favorite wontfixes.
https://issues.scala-lang.org/browse/SI-3836
So you think OK, I will define package-private aliases at the package level and all will be well. Then you run into this one:
https://issues.scala-lang.org/browse/SI-3160
So you go back to repeatedly renaming by way of import, a route which guarantees you'll see a nice mix of names for the same thing in any given source base.
On Thu, Feb 16, 2012 at 7:16 AM, Simon Ochsenreither <simon.ochsenreither@googlemail.com> wrote:
You're absolutely right, Ctrie is less than self-explanatory. Maybe it would be defensible if it were in a package called "concurrent" or otherwise explanatory, but it's in scala.collection.mutable.