Jonathan S. Shapiro wrote:
On Fri, 2005-01-28 at 16:40 +0600, Constantine Plotnikov wrote:Note proposed facets extension has trivial expansion to BitC code. Also described approach to facets does not interfere with design of BitC too much, because it uses fat pointer pattern and does not affect layout of data object to be wrapped and it does not create any hidden fields.
I suggest introducing notion of facet to the language. This is commonly needed construct for system libraries.
We are deferring any object-oriented features. Getting the theory base for the language as it is now is already an overwhelming task.
Also OO features have great impact on the standard library design. I think that deferring them is dangerous decision because it is very easy to get into C++ - like mess on language layer and library layer. Last time I checked ML was still strugling with clean introduction of OO features without breaking the rest of the language.
Simplest example is a stream library stack. There are following standard streams types that are likely to be use by applications: gzip, encrypted, ssl, crc counting, file, HTTP input/output, BEEP input/output etc. In java, it is possible to stack different stream together. In C, the file stream interfaces is completely different from others. To support them all a common infrastructure is needed so they will be able to stack. Facets allow defining common interfaces.However, can you explain why facets are relevant to system libraries?
For C libraries like OpenSSL, and GZip offers own abstractions of the stream filter which are not compatible with each other.
Another problem is virtualizable interfaces. We might want to use the common interface to different implementations.
Another example is a listener pattern from Java. GUI libraries need to call client components back on specific events. Currently in C it is done by monstrous big switch. And even this switch has some void* that allows to find out which control is being modified.
Asynchronous I/O libraries will need to notify clients that some read operation completed. This is also usually done by calling function with specific argument to identify the specific operation.
So argument is that if facets are omitted from the language, they will be reinvented again and again. And it will be done poorly and in incompatible ways.
CapIDL would benefit as there will be simpler to export different implementations of the same interface using facet mechanism supported by language. There would be no need to reinvent dispatcher mechanism that calls different implementations depending on implementation type.Also something like this will be needed for CapIDL anyway.
CapIDL definitely does *not* need language support for facets at all.
Constantine
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
