[boost] Re: Formal Review Request -- Interfaces

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-05-10 12:08:35

> Hi Jonathan,
>
> I took a look at the documentation, and I think, the library could be
> very useful.  If I understand correctly, one of applications would be
> to apply dynamically polymorphic proxies to statically polymotphic
> objects, in order, to, for example, put them into a container.

Yes.

> I had
> similar problem in the past, and solved it by hand.
>
> I have one quetion/suggestion:
>
> Do you think your macro interface is flexible enough to incorporate
> all your future enhancements?  I mean, if you have something like:
>
> BOOST_IDL_BEGIN(IPoint)
>     BOOST_IDL_CONST_FN0(x, long)
>     BOOST_IDL_CONST_FN0(y, long)
>     BOOST_IDL_FN1(x, void, long)
>     BOOST_IDL_FN1(y, void, long)
> BOOST_IDL_END(IPoint),
>
> you can only expand it to something that have the fixed structure:
> start block, one block per every function, and then closing block.
> You cannot,  for example generate more than one class.  I don't know if this
> restriction is too strong, though.  It depends on what you want to do
> next.
>
> The other (minor) problem is that your user has to repeat the
> interface name twice.
>
> So, what I am leading to, is, that,using the technique described in
> http://lists.boost.org/MailArchives/boost/msg79530.php, you could
> remove the above restrictions, and achieve something like following:

I hadn't noticed this -- I'll take a look at it.

>
> BOOST_IDL(IPoint,
>     BOOST_IDL_CONST_FN0(x, long)
>     BOOST_IDL_CONST_FN0(y, long)
>     BOOST_IDL_FN1(x, void, long)
>     BOOST_IDL_FN1(y, void, long)
> )
>
> or, if you are willing to treat macro prefixes for a couple of extra
> parenthesis,
>
> BOOST_IDL(IPoint,
>     (CONST_FN0(long, x))
>     (CONST_FN0(long, y))
>     (FN1(void, x, long))
>     (FN1(void, y, long))
> )

Coincidentally, I'm considering both of these syntaxes. My primary motivation
has been compilation speed, since my rought measurements have shown that in the
regression tests preprocessing takes very little time compared to TMP. However,
extensibility is another important advantage which I hadn't given much thought
to.

> The drawback would be that this would imply a little more involved
> preprocessor programming.  I don't know how you feel about it.  In
> any case, using the above mentioned technique, you can keep it well
> structured and easily extendable.
>
> If you are interested, I can give you more details.

Yes, I'm interested. I'm pretty comfortable implementing the current feature set
with above syntax. I'd certainly be interested in you ideas about extensibility,
however.

Thanks!

> Regards,
> Arkadiy

Jonathan