Re: [reSIProcate] Method namespace issue
Dum questions but could you just undefine the Borland macro?
On 11/2/04 10:24 AM, "Jason Fischl" <jason@xxxxxxxxxxxxxx> wrote:
> Following up on the method renaming fiasco:
>
> The issue is that we've used MethodTypes named, INVITE, CANCEL, BYE,
> MESSAGE, etc. MESSAGE conflicts with a Borland macro. I'd like to
> propose the following change:
>
> rename MethodTypes to use camel case instead of all caps:
>
> // Proposed new names
> namespace resip
> {
> typedef enum
> {
> defineMethod(Unknown, "UNKNOWN", "NA"),
> defineMethod(Ack, "ACK", " RFC 3261"),
> defineMethod(Bye, "BYE", "RFC 3261"),
> defineMethod(Cancel, "CANCEL", "RFC 3261"),
> defineMethod(Invite, "INVITE", "RFC 3261"),
> defineMethod(Notify, "NOTIFY", "RFC 3265"),
> defineMethod(Options, "OPTIONS", "RFC 3261"),
> defineMethod(Refer, "REFER", "RFC 3515"),
> defineMethod(Register, "REGISTER", "RFC 3261"),
> defineMethod(Subscribe, "SUBSCRIBE", "RFC 3265"),
> defineMethod(Response, "RESPONSE", "RFC ????"),
> defineMethod(Message, "MESSAGE", "RFC ????"),
> //_MESSAGE,
> defineMethod(Info, "INFO", "RFC 2976"),
> defineMethod(Prack, "PRACK", "RFC 3262"),
> defineMethod(Publish, "PUBLISH", "RFC draft"),
> defineMethod(Service, "SERVICE", "!RFC"),
> defineMethod(Update, "UPDATE", "RFC 3311"),
> MAX_METHODS
> } MethodTypes;
> }
>
> This means that a MESSAGE method would be referred to as: resip::Message
>
> For backward compatibility, Alan suggested that we can provide a macro
> for the old usage that can be turned off at compile time. My preference
> would be to just make the change (with plenty of notice and consensus)
> and have everybody update their application code.
>
> Are there any other enumerated types that should be renamed while we are
> at it?
>
> Jason
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel