GUI, CLI, UI and how about we sort out what an interface is

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2001-04-04 14:13:29

Clearly there are many types of interface (some of which are for users, some 
like RPC, SOAP, COM, CORBA are not). Also if you think back to ooa/ood 101 
every class has an interface.  I don't think GUI's can be considered in 
isolation, especially as they are normally built on top of one of the others.

If we do we run the risk of including things specific to our interpretation 
of what a GUI should be.  Should the coordinate system be integers or floats, 
2d or 3d as in the case of an user interface built on OpenGL (I like to call 
them GLUIs)?  Does having coordinates make sense at all (eg. for a CLI)?

I think instead we should consider all types of interface first and try to 
determine areas of commonality that can be exploited.  Then meta data can be 
added to allow the addition of features which are specific to a particular 
type of interface.

Both CORBA and COM use IDL files to describe interfaces.  Also in 
Java where reflection is used to describe interfaces.  If we can develop a 
similar system of describing our internal interfaces independent of what 
additional interfaces are going to wrap around them then not only could 
people write cross platform code but the same could be used for all the 
different sorts of interface.

We need to be able to...
* Enumerate interfaces in a module.
* Enumerate members of an interface.
* Enumerate arguments of a function.
* Set/get member variables generically.
* Call member functions generically.
* Attach arbitrary meta data to any part of the interface.

I see three possible approaches
1. Use CORBA/COM style IDL
2. Use templates to describe interfaces
3. Build new language features to support reflection at compile time

1. CORBA/COM style IDL
I personally don't like this option as it means coding in a language other 
than C++ and that kind of defeats the purpose of using C++.  I am not 
existing IDL formats allow what could be described as arbitrary meta data.  
So we would have to work that out still.

2. Templates
I have not tried this option out extensively but I have uploaded a very 
small/incomplete sample here
http://www.firestream.co.uk/option2.tar.gz
Note: This is also another example of the "type vector" I mentioned in an 
earlier post in use.  I am hoping to flesh out some more documentation for it 
when I have time.

3. Compile Time Reflection
If C++ had reflection life would be much simpler.  However would we want the 
performance hit and memory overhead at runtime.  My guess is no.  Instead a 
form of compile time reflection built on templates would be better.  Then 
runtime reflection could be added on top as a set of classes that expose 
parts of the compile time reflection data at run time.

In fact option 2 is pretty close to that already.  However it would be nice 
to keep the existing syntax of class definitions to define the interfaces.  

The problem doing this without extending the language is that there is no way 
to enumerate anything (classes, members of a class or arguments of a 
function).  Given a class you can't even loop through the members and write 
them to std::cout.
  
I have tried writing a small preprocessor to write out meta data about 
classes found in "special" header files (ie with no macros or templates).  
Unfortunately I have accidently deleted the preprocessor and the backup is in 
storage at my inlaws roof space.  But thats ok as it was not very good anyway 
as it was just meant as a proof of concept.  I have a sample of what it does 
and have put it here

http://www.firestream.co.uk/option3.tar.gz

Basically the canvas_app.h was generated from the canvas_app.h2 file.  A 
bunch of member classes which describe the members are added.  It also 
creates names.h which provides string the constants needed.  You can then 
enumerate member functions and variables and set and get. The oot_defs.h file 
has some basic access helpers.

The program I was writing used the wxWindows library and call_dialog.h shows 
how I was able to create simple dialogs based on the meta data stored about 
members. Unfortunately I have since ported the app to OpenGL and dropped all 
the wxWindows code.

Both options 2 and 3 could be fleshed out to include support advanced 
features such as inheritance and template members.

It would also be possible (though not easy) to create a set of classes to 
generate a COM, CORBA or SOAP interface wrapper.

Finally one nice side effect of all this is that it could be used for the 
basis for a persistence library too.

Hamish Mackenzie