• Serg Kovrov (11/11) Jan 20 2007 There were always trends to throw away Phobos as standard library in
• Hasan Aljudy (3/14) Jan 20 2007 My impressions is, the interface of the current standard library
• Serg Kovrov (11/13) Jan 21 2007 For example, for file operations I usually use (that is, my
• Hasan Aljudy (3/18) Jan 21 2007 According to my last char with them on their irc (about 3 weeks ago),
• Lionello Lunesu (4/7) Jan 21 2007 I agree.. It makes a switch to Tango unnecessarily complicated.
• Kyle Furlong (4/16) Jan 21 2007 On the other hand, Tango was designed from the ground up to have a
• Bill Baxter (15/31) Jan 21 2007 I can understand tango wanting to claim legitimacy by taking over the
• Kirk McDonald (9/46) Jan 21 2007 Tango uses the tango.* namespace. For a while, Phobos was still
• Bill Baxter (7/51) Jan 21 2007 Ok, then I misunderstood what the OP's problem was then. He wants Tango...
• Serg Kovrov (33/38) Jan 22 2007 'The OP' is me, I presume =)
• kris (6/50) Jan 22 2007 FWIW Tango has a handful of interfaces as you describe (such as
• Serg Kovrov (10/14) Jan 22 2007 I'd like to point that I have used I/O interface just as example. I see
• kris (6/23) Jan 22 2007 I'd like to think such a notion would be plausible, but it is very hard
• Lionello Lunesu (10/26) Jan 22 2007 In an ideal world, yes :)
• Carlos Santander (4/16) Jan 22 2007 --
• Hasan Aljudy (3/19) Jan 22 2007 Well you know, I wouldn't mind using Tango if it can co-exist with
• donth ave (4/5) Jan 21 2007 best since sliced bread.
• Lionello Lunesu (9/11) Jan 22 2007 I always hoped that we could adopt some other standard library's

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.

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.

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.

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.

"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. 

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? :-)

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

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

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

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.

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

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.

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 :)

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.

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

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 ..

donth ave <d onth.ave> writes:

Serg Kovrov Wrote:
 'official' set of 'standard interfaces' 

best since sliced bread.
--
Anonymity is not a Crime

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.