Thread overview
Scale advocacy
Jul 03, 2011
bearophile
Jul 03, 2011
bearophile
Jul 03, 2011
Ali Çehreli
Jul 03, 2011
Ali Çehreli
Jul 04, 2011
Daniel Murphy
July 03, 2011
A nice and almost funny set of slides (no PDF available, I think) that show how to convince your boss to try Scala, it shows only very basic things:

http://scala-boss.heroku.com/#1

Bye,
bearophile
July 03, 2011
Sorry for the wrong title and the wrong newsgroup :-)

Bye,
bearophile
July 03, 2011
On Sun, 03 Jul 2011 12:44:01 -0400, bearophile wrote:

> A nice and almost funny set of slides (no PDF available, I think) that show how to convince your boss to try Scala, it shows only very basic things:
> 
> http://scala-boss.heroku.com/#1
> 
> Bye,
> bearophile

D's solution to the problem at slide #28 (http://scala-boss.heroku.com/
#28) is similar to Scala's:

const(Account) findAccount(Customer customer,
                           EnergyType energy,
                           Date date)
{
    bool matching(const(Account) account)
    {
        return ((account.servicePoint.energy == energy)
                &&
                isDateInWindow(date,
                               account.moveInDate,
                               account.moveOutDate));
    }

    return front_or_null(find!matching(customer.accounts));
}

I know that matching() could be a function literal in D as well, but I prefer nested functions for code clarity when the criteria is not really short.

Also, although returning the range directly would be more D-like, I've written the following front_or_null() instead of Scala's getOrElse():

import std.range;

// ...

ElementType!Range front_or_null(Range)(Range range)
{
    return range.empty ? null : range.front;
}

The template constraint has proven to be problematic though. I will open a separate thread about that.

Ali
July 03, 2011
On Sun, 03 Jul 2011 20:07:43 +0000, Ali Çehreli wrote:

> import std.range;
> 
> // ...
> 
> ElementType!Range front_or_null(Range)(Range range) {
>     return range.empty ? null : range.front;
> }
> 
> The template constraint has proven to be problematic though. I will open a separate thread about that.

I've figured it out: I've been using "== null" instead of "is null". This fails:

import std.range;

ElementType!Range front_or_null(Range)(Range range)
    if (__traits(compiles,
                 { bool result = ElementType!Range.init == null; } ))
{
    return range.empty ? null : range.front;
}

class C
{}

void main()
{
    C[] c;
    front_or_null(c);
}

Replacing "==" with "is" works:

                 { bool result = ElementType!Range.init is null; } ))

I would have liked this simpler syntax to work:

    if (__traits(compiles, { ElementType!Range.init is null; } ))

but it fails without really telling why. Only if I move that expression into a code context that I can understand what the problem is. Now trying to compile this:

    C.init is null;

produces this error:

Error: is has no effect in expression (null is cast(C)null)

I am grateful for the warning but it was puzzling for a while why the simple template constraint was not working. I guess it was a good decision to suppress the compiler errors in __traits(compiles). I wonder whether __traits(compiles) can be made less strict by eliminating the need for the silly 'bool result' in the delegate above.

But this is not a pressing issue at all. :)

Ali
July 04, 2011
"Ali Çehreli" <acehreli@yahoo.com> wrote in message news:iuqja8$7nl$2@digitalmars.com...
> { bool result = ElementType!Range.init is null; } ))

is(typeof(ElementType!Range.init is null))
__traits(compiles, cast(void)ElementType!Range.init is null)
__traits(compiles, { return ElementType!Range.init is null; })
should all work.