request: macro declaring slice interface's methods

[shaver]

If I have a number of implementations of a given interface, modifying the interface requires changing a lot of boilerplate code, which is both tedious and error-prone.

We solved this problem in XPCOM/xpidl by generating helper macros for each interface, such that you would put in

class mySample : public nsISample
{
public:
    mySample();

    // nsISample interface
    NS_DECL_NSISAMPLE;
private:
    int _sampleInt;
};

rather than hand-typing all of the nsISample method signatures by hand. Would you take a patch that added such a macro to slice2cpp-generated headers? No code bloat for people who don't use it, this time I promise!

Mike

[marc]

Sorry, I'm afraid I don't understand what you mean. What boilerplate code are you referring to?

[vukicevic]

I think the suggestion is for slice2cpp to generate a #define for each interface/class that would contain declarations for the methods defined in that interface. For example, the following slice:

Foo.ice:

module Bar {
  interface Foo {
    void opA (int arg);
    int opB (string s);
  };
};

Would generate as part of Foo.h

#define ICE_DECLARE__BAR_FOO \
    virtual void opA (::Ice::Int, const ::Ice::Context&); \
    virtual int opB (const ::std::string&, const ::Ice::Context&)

so that any FooI implementation would just use ICE_DECLARE_BAR_FOO as part of the class declaration, instead of duplicating the signatures by hand. The only places where the method signature would then need to be written would be the slice source and the method definition (where any mistakes can be caught by the compiler, leading to a "no such method declared in class" error).

[michi]

Originally posted by vukicevic

#define ICE_DECLARE__BAR_FOO \
    virtual void opA (::Ice::Int, const ::Ice::Context&); \
    virtual int opB (const ::std::string&, const ::Ice::Context&)

so that any FooI implementation would just use ICE_DECLARE_BAR_FOO as part of the class declaration, instead of duplicating the signatures by hand. The only places where the method signature would then need to be written would be the slice source and the method definition (where any mistakes can be caught by the compiler, leading to a "no such method declared in class" error).

You can use the --impl switch to slice2cpp to generate implementation stubs (.h and .cpp) file that you can edit. That way, you don't have to write the implementation class definition yourself. Would that meet your requirements?

Cheers,

Michi.

[shaver]

Originally posted by michi
You can use the --impl switch to slice2cpp to generate implementation stubs (.h and .cpp) file that you can edit. That way, you don't have to write the implementation class definition yourself. Would that meet your requirements?

Not exactly: I do use --impl sometimes to generate implementation stubs, but I'm more concerned about having to go and manually add/remove/change a method declaration in each of my interface implementations' class declarations (in some cases I have quite a few), when I change the slice interface. I still have to change the method definitions, but that's not something avoidable. This was a tremendously popular feature when we added it to xpidl, and I'm remembering why now.

I'm happy to whip up a slice2cpp patch in a bit, if I get some time for it.

Mike

[michi]

Originally posted by shaver
Not exactly: I do use --impl sometimes to generate implementation stubs, but I'm more concerned about having to go and manually add/remove/change a method declaration in each of my interface implementations' class declarations (in some cases I have quite a few), when I change the slice interface. I still have to change the method definitions, but that's not something avoidable. This was a tremendously popular feature when we added it to xpidl, and I'm remembering why now.

I'm happy to whip up a slice2cpp patch in a bit, if I get some time for it.

Mike

I see your point. This seems like a sensible idea, thanks!. The penalty in terms of code size is zero anyway, seeing that only #define is involved. I'll add this to the code generator. Stay tuned...

Cheers,

Michi.

[michi]

OK, after consulting with Marc, I have to take back what I said, sorry

The complexity isn't worth the minor gain in convenience, we believe. It's easy enough to copy and paste the signature from the generated header file, or to generate an implementation stub with --impl and to copy and paste from that. Besides, if I see something like

class FooI : public virtual Foo {
public:
    OP_DECL_Foo
    // Other declarations here...
};

I end up having to know and decipher what OP_DECL_Foo does. The obfuscation that creates is likely to outweigh the minor inconvenience of not having to update the implementation class declaration.

In general, it's a fine line between convenience and complexity. One example that springs to mind is TAO. It's so full of "convenient" macros that, in the end, the code looks totally unreadable (at least to me, it does, because I'm not intimately familiar with TAO). One person's convenience feature is another person's obfuscation...

Cheers,

Michi.