[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng updated DIRKRB-158:
-----------------------------
Description:
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}
was:
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}
> 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)
