Och, ich erklär das gern. Aber du hast recht. Dass man diesen Unterschied nicht sofort erkennt, ist eine Eigenschaft von DSL-freundlichen Sprachen: Keine Semikola, Funktionsaufrufe brauchen keine Klammern, Zugriff auf Eigenschaften und Methoden brauchen keine Punkte. Das gleiche könnte man wohl auch in Groovy und einigen anderen modernen Sprachen machen. Und ja, es sind Instanz-Methoden, Scala kann keine Toplevel-Funktionen und statische Methoden werden durch Methoden auf Singletons ersetzt.
Aber kommen wir mal zurück:
Ich würde für Konvenienz neben Days auch direkt Month einführen.
Month(int) - gib mir einen Monat mit int Tagen.
Month(int,String) - gib mir einen Monat mit int Tagen und Namen String.
Wir sollten auch die typischen Bezeichnungen für Tag, Woche, Monat, Jahr direkt als internationalisierten String einfügen. Dann kann sich die Kundschaft für typische Fälle die Anführungszeichen sparen. Internationalisierte Strings gibts mit der Bibliothek Rapture wohl recht komfortabel, hab ich aber noch nicht ausprobiert.
Zum Format:
Das könnten wir mit einem handgemachten Stringkontext machen. Das sähe bei der Verwendung dann z.B. so aus:
date"""$number(day). $name(month) $number(year)"""
Wenn man in den Aufrufen keine Anführungszeichen verwendet, kann man zur Berandung auch einmal, statt dreimal die Anführungszeichen machen. Hinter den Kulissen wird ein String mit einem solchen Präfix wie
date als
StringContext behandelt und der Compiler sucht dann eine Methode namens
date.
Die Methode sollte dann ein DateFormat zurückgeben, das hat:
- eine Methode "to" um ein Datum zum String zu machen.
- eine
PartialFunction "from" um aus einem String ein Datum zu machen.
Der Kalender hält eine Liste mit DateFormats vor. Wenn der User dann einen String parsen will, werden alle partiellen Funktionen durchlaufen, ob eine passt.