Should we really use enums? Maybe try to use the "string" enum pattern instead? about libotr-ng HOT 12 CLOSED

from libotr-ng.

So, this is the list of the ones that I could find right now. In most cases the naming is inconsistent based on whether it's for external or internal use, etc. I'll fix those cases, and start working on fixing each one of these:

client.h/client.c
CLIENT_ERROR_NOT_ENCRYPTED, CLIENT_ERROR_MSG_NOT_VALID returned from otrng_client_receive as an int
this should probably be a regular enum instead to make it more type safe

client_callbacks.h
otrng_smp_event_t
unclear how it's used. need to investigate more

dake.h
otrng_rsign_tag_type_s
unclear how it's used. only two values. maybe can be a boolean instead? or good string chars

dh.h
otrng_participant
only two values. should be possible as a boolean or a char value

error.h
otrng_err_code
otrng_notif
otrng_err

key_management.h
otrng_information_flow - two values
otrng_participant_action - two values
otrng_ratchet_type - two values
session_id_half - two values

otrng.h
all the policy stuff
otrng_state
otrng_supported_version
otrng_version
otrng_in_message_type
otrng_warning

smp.h
smp_state_t

tlv.h
tlv_type_t

from libotr-ng.

The above commit was not related to this issue - it was actually fixing bug #52 in pidgin-otrng.

from libotr-ng.

Is this about not using enums at all in the library?

What is the "string" enum pattern?

from libotr-ng.

Is this about not using enums at all in the library?

Yes. It is about considering avoiding them when it seems unuseful.

What is the "string" enum pattern?

This was proposed by @olabini on an email sent to the team. It basically corresponds to a "good practice" recommended by 21st Century C, chapter 7, "Enums and string". The pattern basically corresponds on using strings for whatever a enum is used for.

from libotr-ng.

otrng_smp_event_t seems to be used both internally and externally, and in such a way that it makes no sense to remove it or change it

from libotr-ng.

We will keep otrng_tlv_type_t for now (but renamed to have the otrng_ prefix). It seems useful as is, and there's no obvious and good way of making a string pattern out of it.

from libotr-ng.

I think otrng_warning is reasonable to keep as an enum for now.

from libotr-ng.

For now, we will leave the policy stuff as is, but there is definitely room for improvement there.

from libotr-ng.

Actually, scratch that. Better to remove the POLICY defines since they are not used. We can add them back with a good design when we get to something that needs them.

from libotr-ng.

otrng_state can stay as an enum for now.
otrng_supperted_version doesn't really make sense at all. I'll leave it for now, with a TODO.

from libotr-ng.

The three enums in error.h all make sense as enums for now (although they need to be renamed).
With that, this issue should be done.

from libotr-ng.