www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Scale advocacy

reply bearophile <bearophileHUGS lycos.com> writes:
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:



Bye,
bearophile
Jul 03 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sorry for the wrong title and the wrong newsgroup :-)

Bye,
bearophile
Jul 03 2011
prev sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
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:
 

 
 Bye,
 bearophile





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
Jul 03 2011
parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
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
Jul 03 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Jul 04 2011