Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 03, 2011 Scale advocacy | ||||
---|---|---|---|---|
| ||||
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 Re: Scale advocacy | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | Sorry for the wrong title and the wrong newsgroup :-) Bye, bearophile |
July 03, 2011 Re: Scale advocacy | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 Re: Scale advocacy | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 Re: Scale advocacy | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | "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. |
Copyright © 1999-2021 by the D Language Foundation