My second issue is enhancing type safety via wrappers.

For example, your DateTime class returns the year as an Int. This loses the static typing and means that I can get the confused with the Int returned when querying the day of the month, or the Int miles to the moon.

Compile-time type-safety can be increased if I can declare (quickly and easily) a wrapper for Int that marks its meaning.

Ideally, the class should also be able to add its own methods specific to the meaning. For example, a DayOfMonth wrapper could have a method to return the maximum value given a month and a year.

The key here is to allow these wrapper classes to be used as though they are an Int. Any method that takes an Int should also accept an Int wrapper. They should also have a literal syntax - probably very similar to a literal syntax for quantities.

wrap Int as Year {
  // provide syntax to expose a set of slots from Int
  // add other slots as necessary
}

Possible literals:

year := Year:2008;
year := Year_2008;

The same principle applies to other types:

wrap String as BookingReference {
  // provide syntax to expose a set of slots from String
  // add other slots as necessary
}
ref := BookingReference:"GT5JU";
ref := BookingReference_"GT5JU";

This can be passed into any method expecting a String. However, it remains type-safe in general.

A key reason to allow this is to add validation. For example, to ensure that a DayOfMonth is only from 1 to 31, or a BookingReference is always 5 alphasnumerics.

Stephen

Similar to null by default post, I think it is just a matter of taste. I definitely like a static type system up to a point, but I also really like dynamic typed languages like Python and Ruby. There is a trade-off to make between type safety and simplicity. So I would definitely lean against adding more fine grained typing like type-safe wrappers.

I think this is perhaps a broader question. I haven't found any language level support for composition instead of inheritance yet in fan.

The inheritance support seems cleaner than Java with classes and mixins. But this still will tend to encourage inheritance when composition might be the better approach. Or do you forsee mixins replacing the need for composition?

To be clear, what I mean is special support to allow a class to easily expose the slots from another class.

JAVA:

public class A {
  public void methodA() {...}
  public void methodB() {...}
}
public class B {
  private A delegate;
  public void methodA() { delegate.methodA() }
  public void methodB() { delegate.methodB() }
}

Stephen

Maybe I misunderstood you - I definitely like the idea of some kind of general purpose composition. Although I think mixins solve a lot of problems I've had with Java. But I'd be interested in exploring other ideas. For example I like the idea of Python decorators (which I consider a mechanism for composition). At some point I'd like to allow using facets to specify decorator functions.