questions on PhanTango 'merger' (was Merging Tangobos into Tango) - long-term vision

[Christopher Wright]

Kris wrote:
> "Marcin Kuszczak" <aarti_nospam at please_interia.pl> wrote in message 
> news:fejdk1$pvv$1 at digitalmars.com...
>> Kris wrote:
>>
>>
>>> And that's where the misconception comes in. The benefits in the high
>>> level of Tango are often based upon the capabilities in the "lower"
>>> levels. Which is why the earlier question had been posed about Tango I/O.
>>> You don't get Tango without the I/O package, because that is one of the
>>> definitive differences between the two libraries. In short, there's
>>> nothing in Phobos that Tango would benefit from. When it comes to I/O, 
>>> for
>>> example, Tango seriously outperforms every other library we've bothered 
>>> to
>>> test. When it comes to string processing, the same is true. This is due 
>>> to
>>> the design of Tango.
>>>
>> I don't want to drop Tango IO. :-)
>>
>> Probably I express myself not enough clear with my idea. It would be great
>> if you could comment on my replay to Larsivi:
>>
>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960
>>
>> Thanks!
> 
> 
> Sure; the quick and easy answer it this: Tango is also a better /low-level/ 
> library than Phobos. Really, it is :)   If you want to get a thin library up 
> and running on a cell phone or whatever, Tango would totally be the right 
> choice. Why? Because the team went to great effort to make the library (a) 
> decoupled and (b) layered.  Not only is the so-called Runtime isolated and 
> is even packaged separately, but the middle and upper layers have limited 
> interdependencies amongst them.
> 
> It's not Utopia, since there are always tradeoffs to make. For example, the 
> Tango logging package was previously distinct from the string formatting 
> package, so you didn't pay the price of the dependency unless *you* wanted 
> it. Well, recently, that changed because the benefit of coupling the two 
> outweighed the isolation benefit. That's a fair example of a trade-off that 
> was somewhat on the fence to begin with, and finally decided which side it 
> wanted to be on :)
> 
> Elsewhere we use a small set of interfaces to decouple the implementation of 
> modules, such that (a) implementation can be plugged in and (b) the 
> implementation modules themselves do not import each other; and are fully 
> decoupled. Altogether, this makes Tango a very good choice as a 
> mobile/modular library to target any kind of environment ... it was 
> /designed/ as such from the beginning, and enjoyed a reasonably long 
> gestation period to explore the various tradeoffs. What's missing from 
> Tango, I understand, is something that's more familiar for those who prefer 
> a free-function model? If so, then I think those folks will find incremental 
> changes in Tango that are moving in that direction. In addition, I promised 
> some folk at the D conference that model would be exposed somehow ... so it 
> is, and will continue to happen :)
> 
> This is what prompted the earlier question: "what pieces of phobos would 
> folks really like to see in Tango?". Or rephrased, What is it /about/ parts 
> of phobos that some people prefer? I'm getting a good indication that 
> certainly some people prefer the free-function aspect? I'd really like to 
> hear more about that, particularly some specifics :)
> 
> I'm asking these questions because nobody has answered the questions posed 
> in the origin of this thread. So instead, this is an exploration of a 
> potentially different approach to a merge.
> 
> What sayeth thou? 

I don't care about free functions versus objects, but I care about the 
amount of typing I have to do. And it seems that object names are about 
as long as function names, and method names are about as long as 
function names, so using an object-oriented interface involves twice as 
much typing.

If you had "alias formatln fln" in Print, for instance, I could just write:
Stdout.fln("whatever");

That's about a three character penalty above writefln, which I wouldn't 
notice. The current seven-character penalty is slightly annoying.

I don't like instantiating objects in order to do a simple test:
if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
}

versus:
if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
}

Personally, I like having these singletons as a matter of organization. 
I could use static imports instead, though.