You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have 2 ways of dealing with symbol conflicts when it comes to COM methods that rely on "overloading". If we have 2 methods within the same type/interface with the same name, we just start putting a number suffix, i.e. Foo, Foo2, Foo3 etc. For symbol conflicts across types an interfaces, they currently all go into their own type/namespace so they don't conflict right now, however, I'd like to include wrapper methods for all inherited interfaces directly in the COM type. To allow this, my current idea is to require all types with this issue to have a set of name variations for each overload. For example, if you have a method Foo1 defined multiple times, you'll need to specify a set of unique suffixes for each variation i.e. FooDog, FooCat, FooCamel, etc. With this mechanism it might be best to require all methods to have a non-empty suffix so as to make it easier for users to follow this pattern. In fact, it might be best to declare a function with the base name that asserts a compile error and lists the available overloads.
Another variation of this is we could have the base function take an enum and the corresponding function, i.e. Foo(.dog)(...), Foo(.cat)(...), Foo(.camel)(...).
Currently we have 2 ways of dealing with symbol conflicts when it comes to COM methods that rely on "overloading". If we have 2 methods within the same type/interface with the same name, we just start putting a number suffix, i.e.
Foo
,Foo2
,Foo3
etc. For symbol conflicts across types an interfaces, they currently all go into their own type/namespace so they don't conflict right now, however, I'd like to include wrapper methods for all inherited interfaces directly in the COM type. To allow this, my current idea is to require all types with this issue to have a set of name variations for each overload. For example, if you have a methodFoo1
defined multiple times, you'll need to specify a set of unique suffixes for each variation i.e.FooDog
,FooCat
,FooCamel
, etc. With this mechanism it might be best to require all methods to have a non-empty suffix so as to make it easier for users to follow this pattern. In fact, it might be best to declare a function with the base name that asserts a compile error and lists the available overloads.Another variation of this is we could have the base function take an enum and the corresponding function, i.e.
Foo(.dog)(...)
,Foo(.cat)(...)
,Foo(.camel)(...)
.Here's some example code exploring options:
Looks like we have about 103 of these overloads within the same type/interface:
The text was updated successfully, but these errors were encountered: