Re: [boost] GUI, CLI, UI and how about we sort out what an interface is

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2001-04-04 16:45:01

> > Will we be able to get at the name of the argument as well as its type?
>
> Yes (but remember that two different declarations can have different
> argument names and XTI can preferve at most one)

Will it issue a diagnostic if it finds more than one?

> > Will we be able to get details about instanciated templates and template
> > members?
>
> XTI can represent instantiations. I hope to get compilers to produce
> sufficient information to present that to users.

What happens if I instantiate a template with XTI information from another 
class.  Will the XTI information be available for template class still be 
available?  (Not sure how well I described that.)

> My development budget is nonexistent. That's one reason I like boost.
> (AT&T Labs - Research is always looking for star researchers, though, so if
> you are about to get a PhD or if you have a research publication record a
> mile long, please think of us (Beeman: sorry for the plug, I couldn't
> resist)).

Doh. Looks like I'll have to keep my day job :-)

> Sorry for posting a teaser only. I'll be giving a design class in San Jose
> next week (at SD20001w) where I'll use XTI as an example. I'll post the
> slides to my home pages.
>
> As soon as I can, I'll post the code also.

Not a problem at all.  It is good to know its coming.  Its like the Lord of 
The Rings Movie.  First we get the teaser trailer next its the posters and 
then we finally get to see it in all its glory.

> What would be a help at this stage would be ideas for how much information
> could be reasonably be presented. "everything" is an unspecified amount.
>
> Remember that I'm talking of optional stuff that a programmer can load into
> a program that needs it. I do not want to burden, say embedded systems
> builders or high-energy physicists. The design maintains the 0-overhead
> principle as far as the language is concerned. This implies that there are
> things that cannot be done and others that cannot be done trivially.
>
> Currently, I represent everything you can find in a class declaration
> (minus function bodies) after preprocessing. I allow every declaration to
> be "annotated" by (name,value) pairs, so in principle a user can add
> arbitrary information.

How about file name and line number for the declaration and definition of 
each class or member.  Then you could allow the user to click on a menu item 
and view the source code of the function that handles it.

I am not sure how related it is but it would also be nice to attach string 
constants as meta data easily.  Currently this is not easy because you must 
define storage for the string.

const char *hello_world = "hello_world";
some_template_class< hello_world > x;

It would be nice if XTI could either reserve a namespace where any name used 
evaluates to a string constant or a class containing that constant in some 
way.  So 

some_template_class< str::hello_world > x;

Better still would be a keyword which would mangle the sting constant to 
product a class name (this also means we could include spaces)

some_template_class< constant_string( "hello world" ) > x;

would be the same as
namespace str { const char *hello_20world = "hello world"; }
some_template_class< str::hello_20world > x;

It could be taken even further though I don't know what the over head issues 
might be.  If...

template< class Type, Type Value >
class constant
{
public:
};

and constant_string( "hello world" ) evaluates to make_tv< constant< char, 
'h' >, constant< char, 'e' >, constant< char, 'l' >, constant< char, 'l' >  
..... >::result;

Then operations on strings at compile time could be made to work....

equal_type< constant_string( "hello world"),
constant_string( "hello ")::template append< constant_string( "world" ) 
>::result >::result

would evaluate as true.

Hamish Mackenzie