Elm'de bir fonksiyonun birden fazla türü almasını sağlayabilir misiniz? Aşırı fonksiyon var mı?

Question

JS'den bir kitaplık yüklemeye çalışıyorum ve bir dizeyi veya dizeleri içeren bir işlevi aldım. Bir dize verildiyse, onu bir dizeler listesine böler ve sonra bunu ilk etapta geçirmiş gibi devam eder.

Kendi türümü tanımlayarak bunu yapabilirim, ancak API'yi çirkin kılıyor ve verilerinizi özel bir Tür öneki gerektiriyor. Ben liman bu tür davranışları desteklemesi gerektiğini sanmıyorum, Nihayetinde

type DocumentBody = Raw String | Words List String 

tokenize: DocumentBody -> List String 
tokenize s = 
    case s of 
     Raw str_body -> String.split " " str_body |> (List.map String.toLower) 
     Words list_body -> List.map String.toLower list_body 

-- Tests 

tests = 
    suite "Tokenizer" 
    [ test "simple" <| assertEqual ["this", "is", "a", "simple", "string"] 
            <| tokenize (Raw "this is a simple string") 

    , test "downcasing tokens: string" <| assertEqual ["foo", "bar"] 
                 <| tokenize (Raw "FOO BAR") 

    , test "downcasing tokens: list of str" <| assertEqual ["foo", "bar"] 
                  <| tokenize (Words ["Foo", "BAR"]) 
    ] 

, ama nasıl yerine türünden sadece numaralandırma üzerinde size desen maçı yapın: İşte

bende ne var örneğimde Raw veya Words önekine mi ihtiyaç duyuyorsunuz?

Answer 1

Hayır, elm işlevlerini diğer dillerde olduğu gibi aşırı yükleyemezsiniz. Her fonksiyonun tek bir imzası vardır. Bir fonksiyonun birçok türde olabilen bir parametreyi kabul etmesini istiyorsanız, bir sendika tipi kullanan çözümünüz gayet iyi çalışır.

API'yi çirkin hale getirdiğini söylüyorsunuz. Buna çirkin demezdim. Belki de tip beyannamesi veya vaka ifadelerinin sözdizimi rahatsız edici değil, ama zaman ayırın. Senin üzerinde büyüyecek. Orada çok fazla güç ve güvenlik var. Kodun herhangi bir varsayım yapmasına izin vermiyorsunuz, her senaryoyu ele almak zorundasınız ve bu, elm gibi bir dilde çalışmanın güçlü yanlarından biri.

Desen eşleme kodunuz uygun. Bunu ötesine kısaltamazsın.

Aynı zamanda, bir javascript kitaplığını yeniden yazma ve ham javascript'ten bağlantı noktaları üzerinden iletişim kurmaya çalışmanın acısını anlayabiliyorum. İşleri çok daha katı bir dilde yeniden yazıyorsunuz ve javascript'in herhangi bir şeyi ve her şeyi kabul ettiği fonksiyon imzalarını çoğaltamayacaksınız. Ama yine, bu bir elm kuvveti, bir zayıflık değil. API'yi sıkılaştırma ve belirsizliği kaldırma fırsatını kullanın.

Spesifik örneğinize gelince, bana göre, çözümünüzün ötesinde birkaç olası alternatif var gibi. tokenize işlevinin başlaması için çok fazla şey vaat ettiğini; çok belirsiz. İşlevsel dillerde kod yazarken, küçük ve karmaşık şeyler tutmayı tercih ederim. Bana göre, her biri tek, belirli bir amaca sahip iki ayrı işlev olmalı.