Hi Stephan, >>> - The owner of an extensible interface can add members to its end >>> (inherited interfaces, methods, attributes). >> Why at the end only? Do we gain something with this restriction, and do >> we gain it in *all* language bindings, or would some bindings "break" >> regardless of it? > > The C++ language binding would not (without modifications I would not > dare to think about) be able to handle anything else (incl. inheriting > from extensible interfaces). So this sketch of a proposal is written > from the perspective of "how can we modify existing interfaces without > the current C++ language binding breaking down when mixing clients > compiled against old interface versions with producers built against new > interface versions." (All other languages should be more flexible here, > so that I assume no extra problems for other language bindings.)
Yes, the "at the end" cried "C++" loudly ... Sadly, this implies that "semantic grouping" of interfaces/attributes gets lost, unless we enhance autodoc to re-introduce this no matter the order in the IDL file. Be it. Better than nothing ... Okay, as next step ;), please let's - with 3.0 or so - make a break with some of the old services which will not be migrated to new interfaces soon, and allow to given them the "extensible" keyword. >>> Not completely thought through, but should probably work. How does that >>> sound? >> Like a great first step towards a living API, which is fun to design, >> without feeling blocked unnecessarily. > > Come on, the real fun is creatively pressing new functionality into > existing, rigid API. :) :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
