www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - standard library vs standard interfaces

reply Serg Kovrov <kovrov no.spam> writes:
There were always trends to throw away Phobos as standard library in 
flavor of some other like Ares, Tango, or whatever. The problem is there 
are lot of code (I'd say most of it) that hard-coupled with current 
standard library.

So why not define well-thought, 'official' set of 'standard interfaces' 
(and standard implementation), as opposite to 'standard library'. It is 
not necessary for a library to fully support all interfaces, of course. 
We could have than any number of third party libraries to work with, in 
a 'standardized' way.

-- 
serg.
Jan 20 2007
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Serg Kovrov wrote:
 There were always trends to throw away Phobos as standard library in 
 flavor of some other like Ares, Tango, or whatever. The problem is there 
 are lot of code (I'd say most of it) that hard-coupled with current 
 standard library.
 
 So why not define well-thought, 'official' set of 'standard interfaces' 
 (and standard implementation), as opposite to 'standard library'. It is 
 not necessary for a library to fully support all interfaces, of course. 
 We could have than any number of third party libraries to work with, in 
 a 'standardized' way.
 

My impressions is, the interface of the current standard library (phobos) IS the standard interface.
Jan 20 2007
parent reply Serg Kovrov <kovrov no.spam> writes:
Hasan Aljudy wrote:
 My impressions is, the interface of the current standard library 
 (phobos) IS the standard interface.

For example, for file operations I usually use (that is, my methods/classes expects) strings (filename) and std.stream.Stream interface. Thankfully we do not need any interface for string operations, but for streams we do. Ares seems uses FILE* handle for that purpose. So, to switch to, or even to use part of Ares I have to rewrite some of my code. Have no idea about Tango, but I'd be surprised if it implements std.* interfaces... -- serg.
Jan 21 2007
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Serg Kovrov wrote:
 Hasan Aljudy wrote:
 My impressions is, the interface of the current standard library 
 (phobos) IS the standard interface.

For example, for file operations I usually use (that is, my methods/classes expects) strings (filename) and std.stream.Stream interface. Thankfully we do not need any interface for string operations, but for streams we do. Ares seems uses FILE* handle for that purpose. So, to switch to, or even to use part of Ares I have to rewrite some of my code. Have no idea about Tango, but I'd be surprised if it implements std.* interfaces...

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.
Jan 21 2007
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"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.
Jan 21 2007
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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? :-)
Jan 21 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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? :-)

I can understand tango wanting to claim legitimacy by taking over the 'std' package namespace, but I think there are still some options that allow interop. For one, Tango could choose a different top-level package that still sounds very legitimate, like d.* or lib.*. Or Tango could make sure all it's std.* subpackages have different names from existing phobos ones. Like std.math2 instead of std.math. [Ok, that makes me barf even though I suggested it] Or Tango could have an installer that allowed installing as both std.* and/or tango.* depending on whether you need to interop with phobos. Or Tango could have an installer that moves *phobos* over to the namespace phobos.*. At least that would allow an easy way to update old code by search and replace of "std." with "phobos." --bb
Jan 21 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 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? :-)

I can understand tango wanting to claim legitimacy by taking over the 'std' package namespace, but I think there are still some options that allow interop. For one, Tango could choose a different top-level package that still sounds very legitimate, like d.* or lib.*. Or Tango could make sure all it's std.* subpackages have different names from existing phobos ones. Like std.math2 instead of std.math. [Ok, that makes me barf even though I suggested it] Or Tango could have an installer that allowed installing as both std.* and/or tango.* depending on whether you need to interop with phobos. Or Tango could have an installer that moves *phobos* over to the namespace phobos.*. At least that would allow an easy way to update old code by search and replace of "std." with "phobos." --bb

Tango uses the tango.* namespace. For a while, Phobos was still available as phobos.*, but I believe it was removed because no one really used it (and it was never "officially" supported, anyway). With sufficient demand, I bet it could be added back in. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Jan 21 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 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? :-)

I can understand tango wanting to claim legitimacy by taking over the 'std' package namespace, but I think there are still some options that allow interop. For one, Tango could choose a different top-level package that still sounds very legitimate, like d.* or lib.*. Or Tango could make sure all it's std.* subpackages have different names from existing phobos ones. Like std.math2 instead of std.math. [Ok, that makes me barf even though I suggested it] Or Tango could have an installer that allowed installing as both std.* and/or tango.* depending on whether you need to interop with phobos. Or Tango could have an installer that moves *phobos* over to the namespace phobos.*. At least that would allow an easy way to update old code by search and replace of "std." with "phobos." --bb

Tango uses the tango.* namespace. For a while, Phobos was still available as phobos.*, but I believe it was removed because no one really used it (and it was never "officially" supported, anyway). With sufficient demand, I bet it could be added back in.

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. --bb
Jan 21 2007
parent reply Serg Kovrov <kovrov no.spam> writes:
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.
Jan 22 2007
parent reply kris <foo bar.com> writes:
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
Jan 22 2007
parent reply Serg Kovrov <kovrov no.spam> writes:
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.
Jan 22 2007
parent kris <foo bar.com> writes:
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 :)
Jan 22 2007
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Jan 22 2007
parent Carlos Santander <csantander619 gmail.com> writes:
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
Jan 22 2007
prev sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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 ..
Jan 22 2007
prev sibling next sibling parent donth ave <d onth.ave> writes:
Serg Kovrov Wrote:
 'official' set of 'standard interfaces' 

-- Anonymity is not a Crime
Jan 21 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Jan 22 2007