mariusMay 8

In my interactions with other go library maintainers I realized I have really strong opinions about how code should look like, and I have a really low patience threshold for explaining why that is.

I guess I've been long enough out of the loop of developing in teams, that I'm no longer able to patiently explain why I prefer certain ways of doing things.

Show threadmarius

In the end after a week of back-and forth I'll have to stop massaging the PR I was proposing due to irreconcilable differences between how me and the maintainer view the absence of a "thing" vs the "thing" being empty.

I won't say I completely wasted my time, but it's still a little unpleasant when reading the same specification leads to such different interpretations. Oh, wait... I've seen this with ActivityPub too, I shouldn't be surprised. But maybe it's time I introspect why this keeps happening to me, or do I need a couple more data points.  

May 11 at 9:55amWeb
Show threadMarcus Rohrmoser 🌻May 11
Hi @mariusor,
json-ld has this whim to be completely lost about #cardinality.
Show threadmariusMay 11
@mro I'm not sure I understand what cardinality is when it comes to JSON-LD.
Show threadMarcus Rohrmoser 🌻May 11

Hi @mariusor,

{foo="bar"}
or
{foo=["bar"]}

{foo=[]}
or
{foo=null}
or
{}

Show threadmariusMay 11

@mro that's what I thought so, but wasn't sure.

Yeah, it's a questionable decision, but probably due to trying to represent data that was initially modeled as XML.

I do hope, though, that there wouldn't be any way to misinterpret that when writing a parser/generator for it. :)

Show threadMarcus Rohrmoser 🌻May 11
@mariusor
xml had a well-defined concept of cardinality - you could even #validate that standalone without the consuming application.