Kragen Sitaker wrote:
>
> On "thinnings":
> > > In particular, more powerful interface variants often
> > > want to return capabilities to less powerful interface variants, and you'ld
> > > like to be able to type check that fact. It helps to know that the two
> > > objects are really the same.
> > >
> > > I have not yet encountered an IDL input language that makes the expression
> > > of this natural.
> >
> > how about introducing a new keyword or two:
>
> The "thins" relationship is the inverse of the "extends" or "inherits
> from" relationship. The more powerful interface is simply a subclass
> of the less powerful interface.
It is definitely not.
There can be many different thinnings of a capability.
eg
interface Foo{
void bar() void baz() void bongo()
interface Foo1 thins Foo{
restrict bongo()
}
interface Foo2 thins Foo{
restrict baz()
}
You could do some wierd inheritance things here, but that would be a hack. Thinnings are not superclasses.
When the original interface is designed, it is unknown which thinnings will be created in future.
You could put each operation in its own interface and say that everything must inherit from every operation it supports. That would be pretty sick - and there would be no way to tell if two different thinnings come from the same original full capability.
Doing this with inheritance is wrong.
This was the whole point of what shap was saying unless I am
mistaken - this does not fit into an inheritance model at all.
Re the bastardised IDL I wrote:
This is not exactly what I envision it looking like in the end..
It may be best to specifically mention every operation you still
support. This would mean that random operations would not get
"left in" by mistake, and new operations added to an interface
would not get propagated to every thinning..
It may also be best to better distinguish between a thinning and an
ordinary interface, eg :
thinning Foo1 thins Foo{
void bar() void baz()
but I can see some situations where you might want to inherit from a thinning, so maybe this distinction is bad.... Also, we might want to get away from the curly brackets & semicolons syntax if we are making our own IDL ;-)
Rob