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