This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-11
Channels
- # announcements (7)
- # aws (52)
- # babashka (16)
- # beginners (49)
- # bristol-clojurians (1)
- # calva (2)
- # chlorine-clover (26)
- # cider (6)
- # clara (1)
- # clj-kondo (79)
- # cljfx (15)
- # clojure (82)
- # clojure-berlin (2)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-france (91)
- # clojure-germany (48)
- # clojure-nl (7)
- # clojure-norway (99)
- # clojure-uk (54)
- # clojurescript (18)
- # code-reviews (9)
- # data-science (2)
- # datalog (15)
- # datomic (15)
- # depstar (20)
- # emacs (4)
- # events (1)
- # fulcro (30)
- # funcool (1)
- # graphql (1)
- # helix (5)
- # jobs (6)
- # kaocha (12)
- # leiningen (8)
- # luminus (1)
- # malli (13)
- # off-topic (73)
- # pathom (12)
- # portal (11)
- # portland-or (1)
- # re-frame (10)
- # reagent (1)
- # reitit (44)
- # remote-jobs (1)
- # ring (19)
- # shadow-cljs (64)
- # tools-deps (32)
Mornin'
morning
i was just introduced to the idea that this is a code smell http://wiki.c2.com/?PrimitiveObsession
and i was like looooooool
using primitive data is good design
not a code smell hahaha
come back to me about primitive data once you've scaled a service that uses microservices or external parties... i don't think your ValueObject
will serialise as easily as 1
primitive-data + language features to enforce type or schema of that primitive data is the killer combo
xactly
i feel like it's quite obvious
but it's very hard to explain to some folks
been using jsonschema on current project cos it's typescript and damn it makes me miss schema
having to write schemas and my types out is booooring
this feels like a convincing argument: if only the types in typescript were themselves plain-old-datastructures, then you could use them to construct a parser for your JSON and your duplication problem would disappear
or if the type system was more powerful you could derive the parsers and encoders from the types https://hackage.haskell.org/package/aeson-deriving#readme
in the end i presume a sufficiently expressive ability to despatch on type is equivalent to having the type-structures available as data, but perhaps safer ?
or, are there things which can't be expressed in one way that can be expressed in the other ? i can't recall anything about this... have you seen anything @U050CJW4Q ?
I think by default it supports simple types and you can write custom convertors for others
ikr??
people look at you funny when you say stuff about getting things for free without having to parse the gen'd ASTs
it's the same as the old unix make-everything-a-filesystem argument - you get compounded benefits from having a uniform means of access
right, which you only get with primitive data
there are lots of nice islands to visit in stockholm
or if the type system was more powerful you could derive the parsers and encoders from the types https://hackage.haskell.org/package/aeson-deriving#readme
yeah noticeable that purescript is weaker than haskell in that regard (afaict anyway, from a novice perspective)
@alex.lynham: I hear what you’re saying, but isn’t the advice behind that essentially saying, don’t use for example Int
to mean EmployeeId
, define a type or spec called EmployeeId
, and use that instead, even if it’s just essentially an alias for Int
?
i.e. it’s better to lift primitives into domain language.
e.g. in clojure.spec: (s/def ::employee-id integer?)
is better than just using integer?
everywhere where you mean employee-id
.
well when you see it in OO context it tends to mean encapsulate it in an object
& even in your example it's just a ref innit, so it's quite different to something inaccessible
back to the data/metadata thing with objects being like metadata that doesn't compose
where e.g. types do compose
because in OO land defining a type entails the baggage of instantiating objects and using objects
i've got no quarrel with types sir
:thumbsup: For them it certainly does mean encapsulating in an object; but I think that’s just because the c2 community and most of that wiki’s content were written circa 2000; by a bunch of smalltalkers, and folk adopting java… so most of it has an OO flavour. Weren’t they just using the tools and language available to them to try and express the more general idea of prefering domain representations to primitive ones?
Nobody likes the drudgery of wrapping/unwrapping things that’s for sure… but sometimes needs must!
100% agree that every class is an island though
i guess the context is that i'm leading a project where we pass around largely domain-specific hashmap representations to avoid messing with classes/objects and we're the only team really being that functional primitive obsessed is a kinda criticism that's been levelled at me a few times as regards coding style and so yes while i think there's historical residue to the definition and indeed a charitable interpretation is 'map your domain well' the reality is i've found it something that OO people prize without understanding the trade off to
because it parses as 'primitive data bad, objects good'
example given in a friendly exchange earlier:
> also toString(Money(7, ‘GBP’)) is different to toString(7)
to which i retorted
['gbp', 7]
(in js, obv in clj you could use :gbp
or a namespaced version
but the idea that instantiating a class for what is self evidently modellable as a tuple or variant while keeping within the bounds of primitive data is wild
and imho dead wrong, but then i am an fp fundamentalist
:thumbsup:
wrong tab craig
more than usual ?
Interesting comments about the c2 stuff. Back in the '90s and early '00s, OOP was still supposed to be the industry's "saviour" and Object Think and OOAD were the One True Way because the whole industry had aligned behind that after procedural and structured programming had failed to shine at scale (complexity scale).