GOd morgen!

God morgen!

God morgen!

god morgen!

hvorfor begrense seg til lusne to tilstander på booleans, sier bare jeg!

Det er veldig mange som ikke skjønner verdien av tre verdier for booleans.

i cljs har vi jo også undefined, two booleans for the price of one

Det gir fullstendig mening 🙂

der undefined tolkes som “har ikke tatt standpunkt”

hvis du legger forskjellig semantikk i nil og undefined så kommer jeg hjem til deg og putter alle kjøkkenknivene dine i oppvaskmaskinen.

Nei, jeg legger ikke ulik semantikk der, men jeg mener det er verdi i å kunne vite hvem som har svart at de kommer på Clojure Lunch, hvem som har svart at de ikke kommer, og hvem som aldri svarer.

Det er fristende, og praktisk, å lese tre states ut av en boolean når den får lov til å være nil, men koden din vil sannsynligvis bli bedre med en eksplisitt modellert tilstand

Må innrømme at jeg er litt farget av å forklare for businessen hvorfor det kan være gunstig å skille mellom “har ennå ikke tatt stilling” og “har tatt stilling og vil ikke”

:thinking_face::thinking_face::thinking_face::thinking_face::thinking_face::thinking_face: er det bra/trygt/gjennomførbart med garantier som “kommer aldri til å være nil” i Clojure egentlig?

hva om den plutselig ble nil lism.. men det er vel lov å se på “var nil når den ikke skulle være nil” som en bug, selv om man ikke har et typesystem

booleans… føles som en slags edge case som default ikke har noe i domene-modellering å gjøre, med mindre du kan argumentere godt for det

litt som bitwise flags og sånt, en rar gammeldags greie man gjør for ytelse eller kompabilitet eller noe

er de “complex” iht til Rich Hickey sin definisjon? Booleans er jo ikke maps/data. Du kan ikke extende en boolean med en ekstra state

litt som at det er lurt å bruke maps som input til funksjoner i stedet for lister, siden det er vanskeligere å legge til et element i en liste og “threade” det igjennom hele call stacken enn å bare slenge på en ekstra key på et map

</tenkehøyt>

Hvorfor er det (nth coll n) og ikke (nth n coll)? Virker som en blemme

Booleans are just enums waiting to happen.

@christian767 Er det ikke sånn at vi vanligvis bruker siste posisjon for ting som skal itereres? I det perspektivet synes jeg det gir mening sånn som det er. Eller ser du på nth som en slags some der man n er det “filteret” man leter etter?

Jeg vil nesten alltid slenge nth inn i en thread-last, og det går ikke

Ja, den generelle formen på clojure.core-funksjoner er "maps først, colls sist" - det bommer nth på.

Hvordan pleier dere løse det? partial?