Formal Review Request -- Interfaces
Hi, I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.) See http://www.kangaroologic.com/interfaces/ for download and documentation. The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented. However, the above version is self-contained and suitable for review, so I would like to propose it now and work on integrating the changes while it is sitting in the review queue. Jonathan
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Monday, May 09, 2005 8:37 PM Subject: [boost] Formal Review Request -- Interfaces
Hi,
I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.)
See http://www.kangaroologic.com/interfaces/ for download and documentation.
The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented. However, the above version is self-contained and suitable for review, so I would like to propose it now and work on integrating the changes while it is sitting in the review queue.
Jonathan
I second the nomination. - Christopher Diggins
On 5/9/05, Jonathan Turkanis <technews@kangaroologic.com> wrote:
The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented.
Just curious, but which half are you planning to knock out? Is Reflection in-scope? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 5/9/05, Jonathan Turkanis <technews@kangaroologic.com> wrote:
The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented.
Just curious, but which half are you planning to knock out? Is Reflection in-scope?
These features will be implemented: Aspect Oriented Programming Runtime Reflection Operator Overloading Self-Referential Interfaces A Template-Based IDL Generalized Function Call Redirection (maybe) Non-Member Functions Qualifiers I guess that more than half. Also, the "Smart References" will be eliminated and replaced by classes with deep-copy semantics. Jonathan
Jonathan Turkanis schrieb:
Caleb Epstein wrote:
On 5/9/05, Jonathan Turkanis <technews@kangaroologic.com> wrote:
The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented.
Just curious, but which half are you planning to knock out? Is Reflection in-scope?
These features will be implemented:
Aspect Oriented Programming
what is boost's position on patents? I'm aware that everything is patented in one way or another but you might at least want to find out if this one is enforced: http://www.pmg.lcs.mit.edu/~chandra/publications/aop.html I save my breath to state my opinion about patents like this. -- Stefan Strasser
Stefan Strasser wrote:
Jonathan Turkanis schrieb:
These features will be implemented:
Aspect Oriented Programming
what is boost's position on patents?
I'm aware that everything is patented in one way or another but you might at least want to find out if this one is enforced:
http://www.pmg.lcs.mit.edu/~chandra/publications/aop.html
I save my breath to state my opinion about patents like this.
From a quick read, it's not obvoious that the interface facilities would be covered by this patent. For instance, there's no "aspect-oriented
Thanks for pointing this out. programming/operating environment" stored in memory. I'm sure this will be discussed during the review. Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote
I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.)
See http://www.kangaroologic.com/interfaces/ for download and documentation.
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. 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: 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)) ) 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. Regards, Arkadiy
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
Jonathan Turkanis wrote: [...]
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.
Here's some PP-code that allows a pretty optimal syntax. Works with GCC and probably nothing else, but maybe it's possible to port to other preprocessors. #include <boost/preprocessor/seq.hpp> #include <boost/preprocessor/tuple.hpp> #include <boost/preprocessor/control/while.hpp> #include <boost/preprocessor/detail/is_unary.hpp> #include <boost/preprocessor/arithmetic/add.hpp> #define GET(x) x, ~ #define GET_II(x) GET_III(x) #define GET_III(x, y) x #define MACRO_D(x, y) (BOOST_PP_SEQ_TAIL(x), \ BOOST_PP_SEQ_PUSH_BACK(y, BOOST_PP_SEQ_HEAD(x))) #define MACRO(n, x) MACRO_D(BOOST_PP_TUPLE_ELEM(2, 0, x), \ BOOST_PP_TUPLE_ELEM(2, 1, x)) #define PRED(n, x) BOOST_PP_IS_UNARY(BOOST_PP_TUPLE_ELEM(2, 0, x)) #define INTERFACE_IMPL_II(x) IS_CONST(x none) #define INTERFACE_IMPL(x) [ qualifiers: \ INTERFACE_IMPL_II(BOOST_PP_TUPLE_ELEM(2, 0, x)) ] [ args: \ BOOST_PP_TUPLE_ELEM(2, 1, x) ] #define INTERFACE_II(x) INTERFACE_IMPL(BOOST_PP_WHILE(PRED, MACRO, x)) #define INTERFACE(x) INTERFACE_II((x, BOOST_PP_EMPTY())) #define EAT_CONST_const #define EAT_CONST_volatile #define EAT_CONST_none none #define IS_CONST_II_const 1, ~ #define IS_CONST_II_volatile 2, ~ #define IS_CONST_II_none 0, ~ #define IS_CONST_III(x, y) x #define IS_CONST_II(x) IS_CONST_III(x) #define IS_CONST_DO(x) IS_CONST_II(IS_CONST_II_ ## x) #define IS_CONST_DO_I(x) IS_CONST_DO(x) #define IS_CONST(x) BOOST_PP_ADD(IS_CONST_DO(x), \ IS_CONST_DO_I(EAT_CONST_ ## x)) INTERFACE( (char&)(int) const volatile ) INTERFACE( (char&)(int) const ) INTERFACE( (char&)(int) volatile ) INTERFACE( (char&)(int) ) preprocessing this with gcc results in: [ qualifiers: 3 ] [ args: (char&)(int) ] [ qualifiers: 1 ] [ args: (char&)(int) ] [ qualifiers: 2 ] [ args: (char&)(int) ] [ qualifiers: 0 ] [ args: (char&)(int) ] -- Daniel Wallin
Daniel Wallin wrote:
Jonathan Turkanis wrote: [...]
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.
Here's some PP-code that allows a pretty optimal syntax.
Thanks, Daniel! I wasn't sure how to handle cv-qualifiers, and so was pretty much resigned to using CONST_FN or something like that, and ignoring volatile in the macro-based IDL. One thing that remains is to figure out how to handle base interface lists and member typedefs. Any suggestions would be very welcome.
Works with GCC and probably nothing else, but maybe it's possible to port to other preprocessors.
I'll definitely need help with that. Jonathan
Jonathan Turkanis wrote:
Daniel Wallin wrote:
Jonathan Turkanis wrote: [...]
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.
Here's some PP-code that allows a pretty optimal syntax.
Thanks, Daniel! I wasn't sure how to handle cv-qualifiers, and so was pretty much resigned to using CONST_FN or something like that, and ignoring volatile in the macro-based IDL.
One thing that remains is to figure out how to handle base interface lists and member typedefs. Any suggestions would be very welcome.
How about: INTERFACE( Base1 , ... ); INTERFACE( (Derived, (Base1)(Base2)(..)) , ... ); For base lists? And I believe this can work for typedef's on gcc: INTERFACE( MyInterface , ((ostream&)(int) const) ((char)(float)) typedef (int, my_type) typedef (float, my_float) ); Again, I don't know how portable these things are. Maybe a PP guru could give us a verdict. -- Daniel Wallin
Daniel Wallin wrote:
Or maybe:
INTERFACE(Derived, extends (Base1) extends (Base2) ... );
Nice.. much better than what I have.. INHERITED(INTERFACE(Derived),Base1) [I don't use multiple inheritance in my interfaces] -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Daniel Wallin wrote:
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.
Here's some PP-code that allows a pretty optimal syntax. Works with GCC and probably nothing else, but maybe it's possible to port to other preprocessors.
Works with Wave as well ;-) Regards Hartmut
participants (8)
-
Arkadiy Vertleyb -
Caleb Epstein -
christopher diggins -
Daniel Wallin -
Hartmut Kaiser -
Jonathan Turkanis -
Rene Rivera -
Stefan Strasser