Kyle Furlong wrote:
> Lionello Lunesu wrote:
>> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:ep0kmq$1csj$1@digitaldaemon.com...
>>
>>> According to my last char with them on their irc (about 3 weeks ago), Tango doesn't conform to Phobos' interface; which is really unfortunate IMO.
>>
>> I agree.. It makes a switch to Tango unnecessarily complicated.
>>
>> L.
>>
> 
> On the other hand, Tango was designed from the ground up to have a coherent, logical interface. Perhaps it should be the standard that *Phobos* has to conform to? :-)

In an ideal world, yes :)

The problem is, even if I'm using Tango, I'd have to fix third-party code using Phobos to get it to compile. I think that's a real pity.

What's more, there's no real need for this. Tango and Phobos should be able to coexist. What's important is that Tango does not depend on Phobos (and the other way around).

For example: toString became toUTF8. It may be more logical, but I don't think it solves any problems and it might create a new one: compatibility.

L.

Serg Kovrov wrote:
> So why not define well-thought, 'official' set of 'standard interfaces' (and standard implementation), as opposite to 'standard library'. 

I always hoped that we could adopt some other standard library's interface, be it .NET or python's modules, or Java, anything!

Learning a new standard library takes much more time than learning a new language. Learning D's syntax is easy, but when you get to actually writing programs, you'll have to dig in to the standard library and you basically have to read it all to know what's where. This process takes a huge amount of time.

L.

Lionello Lunesu escribió:
> 
> The problem is, even if I'm using Tango, I'd have to fix third-party code using Phobos to get it to compile. I think that's a real pity.
> 
> What's more, there's no real need for this. Tango and Phobos should be able to coexist. What's important is that Tango does not depend on Phobos (and the other way around).
> 

I don't think they can coexist, object.d being different, for starters.

> For example: toString became toUTF8. It may be more logical, but I don't think it solves any problems and it might create a new one: compatibility.
> 
> L.


-- 
Carlos Santander Bernal

Kyle Furlong wrote:
> Lionello Lunesu wrote:
>> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:ep0kmq$1csj$1@digitaldaemon.com...
>>
>>> According to my last char with them on their irc (about 3 weeks ago), Tango doesn't conform to Phobos' interface; which is really unfortunate IMO.
>>
>> I agree.. It makes a switch to Tango unnecessarily complicated.
>>
>> L.
>>
> 
> On the other hand, Tango was designed from the ground up to have a coherent, logical interface. Perhaps it should be the standard that *Phobos* has to conform to? :-)

Well you know, I wouldn't mind using Tango if it can co-exist with Phobos ..

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.

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

kris wrote:
> 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".

I'd like to point that I have used I/O interface just as example. I see it to be comprehended hierarchy, that covers every possible generic, and popular domain-specific contracts.

And second, the very idea of having 'standard interfaces' is to have them not just lose-coupled to particular library, but completely independent. Ideally as part of official distribution, but separated from standard library.

-- 
serg.

Serg Kovrov wrote:
> kris wrote:
> 
>> 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".
> 
> 
> I'd like to point that I have used I/O interface just as example. I see it to be comprehended hierarchy, that covers every possible generic, and popular domain-specific contracts.
> 
> And second, the very idea of having 'standard interfaces' is to have them not just lose-coupled to particular library, but completely independent. Ideally as part of official distribution, but separated from standard library.
> 

I'd like to think such a notion would be plausible, but it is very hard to satisfy everyone's desires. For example, look at the opposing forces prevalent in GUI APIs? That doesn't rule out any possibilies, of course; but is intended to identify the often strong social and technical needs to differentiate :)