standard library vs standard interfaces

[kris]

Serg Kovrov wrote:
> Bill Baxter wrote:
> 
>> Ok, then I misunderstood what the OP's problem was then.  He wants 
>> Tango to be a strict superset of Phobos?  Ick.  No thanks.  I agree 
>> that old programs should be able to keep using phobos even after Tango 
>> is installed, but I don't see why Tango should be required to follow 
>> the haphazard 'design-by-accretion' API of Phobos.
> 
> 
> 'The OP' is me, I presume =)
> Something tells me it's gonna take a while... No, I haven't meant Tango 
> to be derived or aimed to be exact replacement for Phobos for sake of 
> compatibility of legacy code. In fact it concerns future code.
> 
> My original point was to have independent set of interfaces, that can be 
> used as expected types. Every library can implement (among their own) 
> some of those interfaces. That way libraries could be combined with each 
> other or even switchable.
> 
> As an example, for a text editor application one could have thee major 
> components - text storage class, text display widget, and driver (main) 
> application. Storage component meant to be initialized by application, 
> by passing an object of a class providing well known, 'standard sream' 
> interface (capable of seeking and writing data). Let it be 
> std.interfaces.IStream (something similar to current std.stream.Stream). 
> For file access application can use something called 
> phobos.io.FileStream (standard implementation of well known I/O 
> interface). But later one could add support for remote storage feature, 
> using third-party library 'Mega I/O'. Something like 
> megaio.net.DavStream, which happens to implement same well known 
> interface, and by that seamlessly fits in.
> 
> Ok, maybe I/O stream interface is not best example, but hope you got the 
> idea. It could be any general interface - archivers, threads, IPC, GC, 
> messaging, widgets... Any possible lib-to-user, lib-to-lib, and 
> user-to-user interaction use-cases.
> 
> As for bottom line, I'd like to have an implementation-agnostic set of 
> interfaces. Considered as 'standard interfaces', but fully separated 
> from standard or (any other library). Defined by authors, potential 
> authors, and potential users of libraries. And of course by authors of 
> standard library. It doesn't have to be fully implemented in standard 
> (or any other) library. It is more like future-proof interfaces.
> 

FWIW Tango has a handful of interfaces as you describe (such as 
tango.io.model.Conduit -- akin to a stream). These were created to 
decouple implementation from reference, so that the lib could remain 
"loosely bound".

- Kris