[ 
https://issues.apache.org/jira/browse/COLLECTIONS-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgeny Kuvardin updated COLLECTIONS-873:
----------------------------------------
    Description: 
In some cases users want to use PatriciaTrie with a unique key and not worry 
about corresponding values. Something like Set + PatriciaTrie.

Now in such cases they may use PatricaiTree  as follows(use the same object or 
null as value):

 
{code:java}
final Object object = new Object();
PatriciaTrie<Object> trie = new PatriciaTrie<>();
trie.put("SMT", null);
trie.put("WAL", object);
{code}
 

Is it a good idea to provide users with such a type of collection?

For example:

 
{code:java}
public class PatriciaTrieSet<K> implements Set<K>, Serializable{code}
 

 

Use case. Take a look at 
[https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java]
{code:java}
for (char ch : allowStr.toCharArray()) {
                    sb.append(ch);
                    if 
(denyPatterns.get(PatternType.PREFIXED).contains(sb.toString())) {
                        hasDominatedDeny = true;
                        break;
                    }
                }
{code}
We check every character instead search in prefix Tree. PatriciaTree is also 
useful but Set is more suitable

  was:
In some cases users want to use PatriciaTrie with a unique key and not worry 
about corresponding values. Something like Set + PatriciaTrie.

Now in such cases they may use PatricaiTree  as follows(use the same object or 
null as value):

 
{code:java}
final Object object = new Object();
PatriciaTrie<Object> trie = new PatriciaTrie<>();
trie.put("SMT", null);
trie.put("WAL", object);
{code}
 

Is it a good idea to provide users with such a type of collection?

For example:

 
{code:java}
public class PatriciaTrieSet<K> implements Set<K>, Serializable{code}
Use case. Take a look at 
[https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java]
{code:java}
for (char ch : allowStr.toCharArray()) {
                    sb.append(ch);
                    if 
(denyPatterns.get(PatternType.PREFIXED).contains(sb.toString())) {
                        hasDominatedDeny = true;
                        break;
                    }
                }
{code}
We check every character instead search in prefix Tree. PatriciaTree is also 
useful but Set is more suitable


> Create Set based on PatriciaTrie
> --------------------------------
>
>                 Key: COLLECTIONS-873
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-873
>             Project: Commons Collections
>          Issue Type: New Feature
>          Components: Set
>            Reporter: Evgeny Kuvardin
>            Priority: Major
>
> In some cases users want to use PatriciaTrie with a unique key and not worry 
> about corresponding values. Something like Set + PatriciaTrie.
> Now in such cases they may use PatricaiTree  as follows(use the same object 
> or null as value):
>  
> {code:java}
> final Object object = new Object();
> PatriciaTrie<Object> trie = new PatriciaTrie<>();
> trie.put("SMT", null);
> trie.put("WAL", object);
> {code}
>  
> Is it a good idea to provide users with such a type of collection?
> For example:
>  
> {code:java}
> public class PatriciaTrieSet<K> implements Set<K>, Serializable{code}
>  
>  
> Use case. Take a look at 
> [https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java]
> {code:java}
> for (char ch : allowStr.toCharArray()) {
>                     sb.append(ch);
>                     if 
> (denyPatterns.get(PatternType.PREFIXED).contains(sb.toString())) {
>                         hasDominatedDeny = true;
>                         break;
>                     }
>                 }
> {code}
> We check every character instead search in prefix Tree. PatriciaTree is also 
> useful but Set is more suitable



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to