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

[BCS]

Reply to kris,

> "Christopher Wright" <dhasenan at gmail.com> wrote in message
> news:fel8ir$1crd$1 at digitalmars.com...
> 
>> 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.
>> 
> Noted, and thank you
> 
>> 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
>> }
> This is definately a pain point I've heard often. The approach in
> Tango would be something like:
> 
> auto path = FilePath ("some path");
> if (path.exists && !path.isFolder) {
> // do stuff
> That's not so bad, is it? But yeah, I'd really like to hear more about
> this
> one in particular, because it seems to be a litmus test in some ways.
> Thanks!
> .

with opImplicitCast you could get:

if (new FilePath(path).exists(path).isFolder(path))


using somthing like this:

class FilePath
{
    struct Sub
    {
        FilePath fp;
        bool val = true;
        Sub Predicate(...)
        {
           auto ret = *this;
           ret.val &= test;
           return ret;
        }
        bool opImplictCast(){return val;}
    }
    Sub opImplictCast(){Sub ret; ret.fp = this; return ret;}
}