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:

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

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:
 
 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
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