223533 - Addition of method prefixes to xpidl generated headers

Status: RESOLVED WONTFIX

(Core :: XPCOM, enhancement)

Description

[Stef Walter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031016 Firebird/0.7+

While adding scripting to a mozilla based application I have the need to
implement interfaces with the identical method or property names on the an
object. For example one interface an exposed to script, while the other is used
internally by the application. In many cases the names of these methods or
properties overlap. 

As expected the header files that xpidl generate conflicts in these cases as
member functions are being redefined. I guess this could be resolved by
#defining functions to different names, or use of sed on the header files. But
as perhaps others might be running into the same issues, here's an enhancement
to xpidl which can add a prefix to member function names. 

See the patch for details.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Stef Walter]

Attachment: Patch to add feature

Comment 2

[timeless]

err. this sounds wrong, i'm fairly certain you can do what you need without
doing this.

Comment 3

[Stef Walter]

Yes there are other ways to solve this problem:

 - Use of #define's to rename conflicting methods
    (tedious but doable)
 - Implementing the interfaces on different objects 
    (adds lots of unneeded complexity)

Not to hold up MS-COM as an example but the #import directive in VC++ allows you
to rename interface methods or properties for cases like this. 

As I'm sure you're aware changing the name for a C++ caller side of an interface
does not affect functionality or method calls at all. Case in point, xpidl
already renames the functions by capitalizing them. vtbl order is what matters.

If nobody thinks this patch is a good idea, no worries, I'll rename the methods
some other way. But I thought I'd give this enhancement to xpidl a shot, as it's
unobtrusive.

Comment 4

[David Bradley]

I'm going to throw this out on the XPCOM news group. I think it's a valid issue,
what I'd like to see if there might be other people who would like it or if
there might be other solutions as well.

Comment 5

[Doug Turner (:dougt)]

what Benjamin said and I agree.  

I don't think it would hurt, but I don't really see why it is needed: in general
anonymous nested classes are the preferred way to solve these name conflicts, at
least according to Don Box. 

Comment 6

[David Bradley]

That's extra work since xpidl won't generate that for you, but given that it's
probably not a common case, the pain of manually doing it is probably not great
enough to warrant the added complexity.

I'll resolve WONTFIX if no further arguments come in the comming days.

If this was going to be addressed, I'd rather see a utility that generated the
implementation class's declaration using nest classes. It would certainly be
more work.

A side note, the reference to "anonymous" threw me off. I was thinking anonymous
as in Java's anonymous classes, which C++ doesn't have.

Comment 7

[Stef Walter]

I've looked at various other solutions and i've settled on adding a few short
perl scripts to my build process. This is the simplest solution (both for the
xpcom interface headers, and for the implementation classes). These scripts
munge the headers and add the method prefixes.

Please feel free to mark this WONTFIX or whatever seems appropriate.