Morning

Mornin'

👋

Good Morning!

¡mån¡

morning

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

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

haha

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

"Deploy first. Think later. It's the natural order."

SQL is broken.

more than usual ?

No. Well, maybe.

I want to join to multiple things but retain the tree shape.

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).