Why JSON::Serializable uses @[JSON::Field], not @[JSON::Property]?

Crystal Contrib
1

Does anybody know why @[JSON::Field] was chosen?

JSON standard itself doesn’t seem to define how to call names on the left in JSON object.

I understand that @[JSON::Field] is short and is most googleable. I’ve tried googling JSON field, JSON property, and JSON attribute and they seem to be in use in this order.

I’m searching GitHub issues and PRs and can’t find where the decision to use @[JSON::Field] in JSON::Serializable was made. Other discussed options seem to be at least @[JSON::Attribute].

I wonder if @[JSON::Property] is more coherent with normal Crystal property than @[JSON::Field], e.g.:

@[JSON::Serializable]
class Point
  @[JSON::Property]
  property x : Int32

  @[JSON::Property]
  property y : Int32
end

I like @[JSON::Field] being short, but @[JSON::Property] seem to be closer to Crystal, and also maybe more universal if formats other that JSON considered (@[YAML::Property] etc.)

1 Like
2

Attribute–value pairs. Name and key values are inside “fields” (double quotes), if you will. That’s what comes to my mind at least

3

Probably because that’s just what the person that implemented the feature picked and no one had a better name when it was in review.

I think ideally there would be a common set of annotations that every format can use, versus every format requiring its own annotation.

I restarted a discussion about it Possible to serializer/deserialize and object like Ruby marshaling? - #15 by Blacksmoke16.

I also am in the process of refactoring my serialization shard to take this approach. CrSerializer - github.com/Blacksmoke16/CrSerializer. Currently it only supports JSON, but adding YAML/other formats is doable without having to redefine the common logic again and again.

1 Like