standard library vs standard interfaces

[Serg Kovrov]

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.

-- 
serg.