directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <>
Subject [jira] [Commented] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
Date Fri, 06 Feb 2015 06:50:34 GMT


Kai Zheng commented on DIRKRB-158:

Logging this great idea for future's consideration when having the time.

> Decouple the mixed aspects in EncodingOption in kerby-asn1
> ----------------------------------------------------------
>                 Key: DIRKRB-158
>                 URL:
>             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

> 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(),
> 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
> 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
> {noformat}

This message was sent by Atlassian JIRA

View raw message