LazyInterface (simplified Boost.Interfaces)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Sep 24 07:53:54 PDT 2010


On 9/23/10 14:13 CDT, kenji hara wrote:
> I supported covariance of return types.
> Please check it.

Excellent! And sorry, indeed I got it backwards: if the interface 
returns e.g. long, the implementation is allowed to return int. 
Generally if the interface returns T, the implementation is allowed to 
return any U implicitly convertible to T.

> 2010/9/24 kenji hara<k.hara.pg at gmail.com>:
>> Thanks very much!
>>
>>> If you agree, I am committed to advocate adopting this abstraction for Phobos in module std.typecons, with credit.
>> Of couse, I agree.

Perfect, thanks! Stay tuned.

>>> All - a bit of bikeshedding - what is a better name for adaptTo? I know there is a consecrated name for such late matching of an interface, but I can't remember it.
>> from here(http://www.coderage.com/interfaces/), I found two keywords.
>> - Non-intrusive dynamic polymorphism
>> - Aspect Oriented Programming
>> How about you?

Well the first term is, I think, invented by the author of the 
Interfaces Boost library, and the second is unrelated. I discussed your 
implementation with Walter and he recognized it as an instance of 
structural conformance. Indeed, check this paper that does the same for 
Java: http://tinyurl.com/2ct69t7.

I think adaptTo should be therefore called structuralCast.

Also, Kenji, I very much recommend you read this paper: 
http://tinyurl.com/2e3vmmx. It contains further idea on how you can 
extend structuralCast to multiple interfaces. I actually have some old 
code that might help there.

Here are a few more suggestions for future work:

* The object returned by structuralCast should offer the ability to 
access the original object, be it via an explicit function or an 
implicit mechanism such as alias this.

* structuralCast should work with a struct as input. The object returned 
stores a copy of the struct inside and implements the interface in terms 
of calls to the struct's member functions.

* structuralCast should work with a pointer to a struct as input and 
work as above, except it doesn't make a copy - it stores the pointer and 
forwards method calls to it. (This is unsafe.)

* structuralCast should work to cast a struct to another. The 
requirements for accepting a structural cast from S to T are as follows:

a) T must be a prefix of S, i.e. all fields in T appear in the same 
order and with the same names at the beginning of S. For example:

struct Point2D {
   int x, y;
}

struct Point3D {
   int x, y, z;
}

struct Point2DColor {
   int x, y;
   Color color;
}

struct Point3DColor {
   int x, y, z;
   Color color;
}

In the example above, Point2D is a prefix of all others, and Point3D is 
a prefix of Point3DColor.

b) All fields that are common to S and T must be public in both. 
structuralCast should not give access to private data and provide 
opportunity for breaking invariants.

If these conditions are satisfied, then given a reference or a pointer 
to S, structuralCast gives you back (safely) a reference or a pointer to 
T. The implementation is a simple cast of pointers, but the point is 
that the function is @trusted, i.e. it provides a safe restricted 
interface over the unsafe cast.


Andrei


More information about the Digitalmars-d mailing list