directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
Date Fri, 06 Feb 2015 06:47:35 GMT
Kai Zheng created DIRKRB-158:
--------------------------------

             Summary: Decouple the mixed aspects in EncodingOption in kerby-asn1
                 Key: DIRKRB-158
                 URL: https://issues.apache.org/jira/browse/DIRKRB-158
             Project: Directory Kerberos
          Issue Type: Improvement
            Reporter: Kai Zheng


Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture of things
in it.

Typically, we have some encoding type like BER/CER/DER, mixed with other unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).

I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the enum (isConstructed(),
etc...)

I wonder if using a specifig field for each of those flags would not be better ?

Something like :

public abstract class AbstractAsn1Type<T> implements Asn1Type {
    private boolean pc    // Primitive/constructed
    private boolean lengthType;  // Definite/Undefinite
    private EncodingType encoding;     // BER/CER/DER/XER/PER
    ...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. 
We should divide them. It's good to have specific field for each of the aspects as you listed,

marked as 'private', and providing 'public' get methods to them, 
and in codes we use the methods instead of those fields. 
In some future we can optimize these fields out using a bit vector or 
an int to flag them.
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message