Kilka godzin pracy z F# w Visual Studio i kilka niespodzianek już za mną. Zainstalowanie Visual F# Tools (pozwalające tworzyć projekty F# w Visual Studio) jak się okazuje to był dopiero początek.
1. Kolejność plików fs ma znaczenie i ten z ‘main’, musi być ostatni
Jakże się zdziwiłem, gdy po dodaniu jakiegoś pliku fs dostałem błąd:
A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence, and can only be used when compiling to a .exe
Szybki rekonesans pokazał, że faktycznie jest coś takiego jak Move Up/Move Down, które możemy wykonywać na plikach:
Po przesunięciu Program.fs na dół, wszystko się pięknie skompilowało. Normalnie czasy C++ mi się przypomniały, że trzeba ręcznie dbać o kolejność includowania zależności. To ciekawy temat, skoro F# potrzebuje ręcznego zarządzania kolejnością kompilacji, pytanie czemu? Natknąłem się na ciekawy wpis na ten temat "Cyclic dependencies are evil". Pada tam bliskie memu sercu pytanie "'why can't F# be like C#'. If you are coming from C#, you are used to having the compiler connect everything automatically". Polecam przeczytanie artykułu, aczkolwiek odpowiedź jest dość prosta - aby wprost zakazać cyklicznych referencji. Na poziomie kodu. Bo są złe. Bo psują strukturę i czynią warstwy bezsensowymi. Innymi słowy, lista plików w solucji F# jest listą warstw down-top i koniec. Na początku się zdziwiłem i zbulwersowałem. Potem przyjąłem to spokojnie na zasadzie "skoro tak, to pewnie ma to sens".
2. Brak natywnego wsparcia dla folderów w F# Tools
Powiedzmy, że dałem się przekonać, że podejście z kolejnością kompilacji ma sens. Oczywistym krokiem było więc zorganizowanie warstw (plików) w foldery. Miałbym folder Helpers (tak wiem, ble..), Models, ViewModels itd. Ale tutaj jeszcze większe zdziwienie - pod Add nie ma możliwości dodania folderu! Jak się okazuje, tak po prostu na razie jest. Możemy sobie foldery ręcznie dodać w pliku fsproj opisującym projekt, ale specjalnie mi się to nie podoba. Okazuje się, że taką możliwość, i wiele innych, umożliwia nam dodatek Visual F# Power Tools. Ale, patrząc na opis tego dodatku odnośnie folderów...
This feature is disabled by default. Because there are known issues with F# Project System in Visual F# Tools, folder organization may not work 100% correctly in all cases.
- We do not advice you to introduce complicated folder structure within F# projects.
- You should keep number of folders within your project as low as possible.
No dobrze. Zatem w pełni świadom zagrożenia, zaznaczyłem w opcjach F# Power Tools opcję Folder organization i udało mi stworzyć wymarzony folder:
Z folderami trzeba się obchodzić jak z jajkiem - nie może być dwóch o tej samej nazwie (niezależnie od poziomu zagnieżdzeń na jakim są) itp. Ale przynajmniej są.
3. Dość surowe wsparcie Visual Studio
Zaskoczyło mnie dość małe wsparcie Visual Studio. Nie ma między innymi tak przydatnego "resolve unopened namespace", które podpowie nam, którego namespace nie zaimportowaliśmy w kodzie. Z tego względu, m.in. lepszego kolorowania składni, jak i powyżej wspomnianych folderów, zdecydowanie polecam doinstalowanie Visual F# Power Tools:
Domyślne kolorowanie składni
Kolorowanie składni po zastosowaniu Power Tools