questions on PhanTango 'merger' (was Merging Tangobos into Tango)

Kris foo at bar.com
Tue Oct 9 20:30:14 PDT 2007


> Would the Tango developers consider merging Tangobos into current Tango in 
> order to have a standard solution to the problem?

Merging Tangobos into Tango would appear to make only a minor difference 
when one can simply downloading Tangobos instead? So it's not clear what 
real benefit that would bring? However, it tends to imply the Tango folks 
would have to maintain that relationship "long-term" ... we already have 
more than enough on our plate as it is :)

This does raise two items of interest: what does that "maintain" word mean 
with regard to Tango, and what does a PhanTango 'merger' actually mean to 
people ...

1.
------
We're always open to new and interesting functionality in Tango, but what's 
needed more than that is a commitment from the contributing author to 
potentially maintain that contribution (at least in the short term).

In addition, the dsource project tango.scrapple is becoming populated with 
all kinds of Tango related goodies, so that's an alternate home for 
compatible code. This is a like a sort of holding-tank for code that could 
make it into the library proper, but is being tried on first, by the 
community, to see if it fits. Still, that code needs to be maintained also 
(as/if needed).

Speaking of which, the owners of these packages obviously do maintain them: 
http://dsource.org/projects/tango/wiki/TangoUsers

In short, a key aspect of the Tango and related functionality is an implicit 
"commitment to maintain".  This has not been an issue for library 
contributions made thus far, however, the whole 'commitment' aspect is quite 
relevant to the topic at hand: e.g. Tangobos


2.
------ 
What it is that people *really* want out of the compatibility effort? To my 
knowledge nobody from the NG has articulated that yet, though the assertion 
has thus far been "the runtime, and object.d". The latter would provide 
compatibility for 'toString' and the GC, but there's a slew of other items 
to consider.

We had expected to try and make the Exception hierarchy of Tango support the 
(much smaller) set of phobos exceptions, for a start. But what about 
Threads? Tango threading is quite different in both extent and 
implementation, and also supports Fibers. Taking all those into 
consideration (which we have) would provide a rudimentary level of 
compatibility, somewhat similar to Tangobos. Then there's the import-path to 
consider, which is quite different between Tango and Phobos.

Moving along  we could consider high-impact items such as I/O. Yet, such 
things are much more difficult to make compatible ... are those the kind of 
things people expect also?

So perhaps the big question here is this: how, and to what depth, do people 
wish for a level of compatibility?  For example, how much value is there if 
this code is portable:

#   void main()
#   {
#      auto x = new Object;
#      auto y = x.toString;
#   }

but this code is not:

#   import tango.io.Stdout;
#
#   void main()
#   {
#      auto x = new Object;
#      auto y = x.toString;
#      Stdout.println (y);
#   }

and this code is not:

#   import tango.io.File;
#
#   void main()
#   {
#      auto content = File("myfile").read;
#   }

You might feel these are trivial differences and, indeed, those examples are 
deliberately chosen as superficially similar. As you might imagine, it 
becomes progressively harder to mask such differences the deeper one digs. 
Some have suggested essentially 'mounting' the Phobos API on top of the 
Tango model. That would work fine for almost everything but, again, it's a 
question of manpower and a long-term maintenance commitment (if someone is 
willing to take that on then, please, do stand up)


Comments?





More information about the Digitalmars-d mailing list