Nie ma nic złego w niejawnych konwersjach. Nawet jeśli biblioteka Java nie była używana dla logiki bazowej, każda rozsądnie zaprojektowana czysta biblioteka Scala nadal używała implicite, pozwalając na pisanie wyrażeń, takich jak 5.days + 3.minutes
.
Nie wszystkie implicity są również równe, niejawna konwersja do bardzo specyficznego typu, nad którym masz pełną kontrolę, jest prawie na pewno bezpieczna.
Jak już wspomniano, takie konwersje będą w większości przypadków zoptymalizowane, zwłaszcza przy włączonej analizie ucieczki, więc nie pozwól im się martwić!
Dopóki JSR 310 nie zostanie sfinalizowany, czas joda jest najlepszy, jaki otrzymasz.
Oprócz konieczności przestrzegania konwencji nazewnictwa w języku Java i braku przeciążania operatorów, czas pracy w jodzie jest już bardzo dobry dla idiomatycznej Scala. Projekt ma bardzo funkcjonalny charakter, zwłaszcza w tym sensie, że obejmuje on nieusuwalność, więc czas na skalach jest w rzeczywistości tylko bardzo cienkim opakowaniem w bibliotece.
Dostajesz również korzyści, że skalaj-czas można łatwo zaktualizować do używania JSR 310, gdy jest on dostępny, więc migracja kodu będzie o wiele mniej bolesna w tym czasie.
Od 2,8, scala czasie została zmieniona scalaj czasie: http://github.com/scalaj/scalaj-time
Szukasz czegoś, co zapewnia <, > operatorów? –
Sugeruję, abyś pozbył się irracjonalnego strachu przed niejawnymi konwersjami. ;-) – Jesper
@Timo - Chciałbym operacji porównania, wraz z takimi rzeczami jak + i minus. @Jesper - Strach nie jest całkowicie irracjonalny. Implicits osiągają lepsze wyniki. Mogą wywoływać dziwne interakcje z takimi rzeczami jak równość. Opierają się na wnioskach o typie i odkryłem, że mieszanie wielu rzeczy, które opierają się na wnioskach typu, jest dobrą receptą na całkowite zamieszanie. –