Ctrie naming

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#367

Thanks!


Simon

https://issues.scala-lang.org/browse/SI-5486

Re: Ctrie naming

Added by extempore on 2012-02-16, 16:31


On Thu, Feb 16, 2012 at 7:16 AM, Simon Ochsenreither <simon [dot] ochsenreither [at] googlemail [dot] com> wrote:

is it possible to change the class name of Ctrie to something more in line with the style guide out there?

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.

Re: Ctrie naming

Added by prokopec on 2012-02-16, 17:01
On 2/16/12 4:21 PM, Paul Phillips wrote:
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 [dot] ochsenreither [at] googlemail [dot] com> wrote:

is it possible to change the class name of Ctrie to something more in line with the style guide out there?

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.

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

Re: Ctrie naming

Added by extempore on 2012-02-16, 17:21


On Thu, Feb 16, 2012 at 7:52 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] 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.)

Re: Ctrie naming

Added by dcsobral on 2012-02-16, 19:01

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?

Re: Ctrie naming

Added by extempore on 2012-02-16, 20:11


On Thu, Feb 16, 2012 at 9:56 AM, Daniel Sobral <dcsobral [at] gmail [dot] 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.

Re: Ctrie naming

Added by prokopec on 2012-02-16, 17:31
On 2/16/12 5:18 PM, Paul Phillips wrote:
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 [dot] prokopec [at] epfl [dot] 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

Re: Ctrie naming

Added by ichoran on 2012-02-16, 18:01
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> 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> 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

Re: Ctrie naming

Added by prokopec on 2012-02-16, 18:11
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 [dot] prokopec [at] epfl [dot] 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 [dot] prokopec [at] epfl [dot] 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

Re: Ctrie naming

Added by prokopec on 2012-02-16, 18:21
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:
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 [dot] prokopec [at] epfl [dot] 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 [dot] prokopec [at] epfl [dot] 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

Re: Ctrie naming

Added by ichoran on 2012-02-16, 18:31
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> 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> 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> 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

Re: Ctrie naming

Added by Aleksandar Prokopec on 2012-02-16, 18:41
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:
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 [dot] prokopec [at] epfl [dot] 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 [dot] prokopec [at] epfl [dot] 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 [dot] prokopec [at] epfl [dot] 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


Re: Ctrie naming

Added by ichoran on 2012-02-16, 19:11
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 [dot] prokopec [at] gmail [dot] 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 [dot] prokopec [at] epfl [dot] 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> 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> 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



Re: Ctrie naming

Added by Viktor Klang on 2012-02-16, 18:51

ConcurrentTrieMap?

On Feb 16, 2012 6:30 PM, "Aleksandar Prokopec" <aleksandar [dot] prokopec [at] gmail [dot] 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 [dot] prokopec [at] epfl [dot] 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> 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> 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


Re: Ctrie naming

Added by Simon Ochsenreither on 2012-02-16, 19:31
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...

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland