I don't like it because it is "create from scratch"-only information. When parsing values it will always stay nil, so it's really an encoding directive. In addition tagging == :IMPLICIT doesn't really do anything, too.
But I like the convenience it gives you for encoding explicitly tagged values, because wrapping them in an array as the value of an ASN1Data first (which is what you would have to do with krypt) is painful.
So, I thought about it and I had an idea: what if we would make :EXPLICIT another "tag class"? Internally, tag_class == :EXPLICIT would be handled as follows: set the actual tag class to :CONTEXT_SPECIFIC and set an internal explicit flag that is to be recognized when encoding the value. This would nicely handle the "encode-only" aspect and it wouldn't introduce a basically worthless instance variable.
This would of course not guarantee one-to-one compatibility with OpenSSL::ASN1 code, but if properly documented, I think we could afford the break for Ruby 2.0.0. I'd like to avoid the 'tagging' attribute for krypt, but I'd also want to avoid having to maintain a branch of krypt as the replacement for OpenSSL::ASN1 in Ruby 2.0. This new approach would IMO be a good compromise for both "worlds" and would allow us to maintain one single code base.
(See also Issue #9)
I had an idea about #tagging:
I don't like it because it is "create from scratch"-only information. When parsing values it will always stay nil, so it's really an encoding directive. In addition tagging == :IMPLICIT doesn't really do anything, too. But I like the convenience it gives you for encoding explicitly tagged values, because wrapping them in an array as the value of an ASN1Data first (which is what you would have to do with krypt) is painful.
So, I thought about it and I had an idea: what if we would make :EXPLICIT another "tag class"? Internally, tag_class == :EXPLICIT would be handled as follows: set the actual tag class to :CONTEXT_SPECIFIC and set an internal explicit flag that is to be recognized when encoding the value. This would nicely handle the "encode-only" aspect and it wouldn't introduce a basically worthless instance variable.
This would of course not guarantee one-to-one compatibility with OpenSSL::ASN1 code, but if properly documented, I think we could afford the break for Ruby 2.0.0. I'd like to avoid the 'tagging' attribute for krypt, but I'd also want to avoid having to maintain a branch of krypt as the replacement for OpenSSL::ASN1 in Ruby 2.0. This new approach would IMO be a good compromise for both "worlds" and would allow us to maintain one single code base.