You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Kai Zheng (JIRA)" <ji...@apache.org> on 2015/02/06 07:50:34 UTC
[jira] [Commented] (DIRKRB-158) Decouple the mixed aspects in
EncodingOption in kerby-asn1
[ https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308713#comment-14308713 ]
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: 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)