Add Crystal

[dsisnero]

Add Crystal Language generation -

[baywet]

Hi @dsisnero Thanks for reaching out. This is something we're unlikely to work on at this point unless we see additional popular demand (others reading this comment, please add a thumbs up to the initial post to help us track demand if you'd like to see support for this language). If this is something you'd like to implement, we'd be happy to guide you through. A lot of the ruby work can probably be reused as far as I understand.

[dsisnero]

Is there a document that shows how to add a language?

[baywet]

not today unfortunately as all languages available at this point have been implemented by internal contributors.

But I can provide pointers on this conversation, the first step would be to implement the abstractions library for the language. Most importantly the:

• request information class
• Serialization writer interface
• Parse node interface
• request adapter interface

from this first work we'll be able to know what models and request adapters need to look like, and start working on the generation side. We already have "examples" in multiple languages for you to look at (I'm guessing Ruby will be the closest to Crystal?) Before those packages get their own repo, we usually collocate them with the generator. (currently only Swift is in that state if you look at the repository).

If you want a better view of all the work that's required to get a language working end to end, you can look at all the swift issues

Let me know if you have additional questions.

[andreaTP]

I'm sympathetic to this effort, this is a small detail, but opened this: https://github.com/std-uritemplate/std-uritemplate/issues/84 If someone will contribute I'll be happy to review, otherwise I'll eventually do it anyhow 🙂

[dsisnero]

Thanks for the information. I am trying to figure out how to wrap the Parse node interface with the way Crystal libraries serialize JSON, YAML, etc. To serialize, and deserialize from Crystal - this is how it is usually done - a similar include Y

JSON::Serializable YAML::Serializable

require "json"

class Location
  include JSON::Serializable
  include YAML::Serializable

  @[JSON::Field(key: "lat")]
  @[YAML::Field(key: "lat")]
  property latitude : Float64

  @[JSON::Field(key: "lng")]
  @[YAML::Field(key: "lng")]
  property longitude : Float64
end

class House
  include JSON::Serializable
  include YAML::Serializable
  property address : String
  property location : Location?
end

house = House.from_json(%({"address": "Crystal Road 1234", "location": {"lat": 12.3, "lng": 34.5}}))
house.address  # => "Crystal Road 1234"
house.location # => #<Location:0x10cd93d80 @latitude=12.3, @longitude=34.5>
house.to_json  # => %({"address":"Crystal Road 1234","location":{"lat":12.3,"lng":34.5}})

houses = Array(House).from_json(%([{"address": "Crystal Road 1234", "location": {"lat": 12.3, "lng": 34.5}}]))
houses.size    # => 1
houses.to_json # => %([{"address":"Crystal Road 1234","location":{"lat":12.3,"lng":34.5}}])

Anyone have any ideas, or should I just re-implement Crystal serialization by converting the java or csharp code?

[andreaTP]

@dsisnero I think that:

should I just re-implement Crystal serialization by converting the java or csharp code?

would be the way to go, you can internally rely on the low-level primitives of Crystal ser/de but the exposed interface should be similar to what you find in C# and Java.

[baywet]

A couple of principles to keep in mind:

• we don't want the generated code to depend on anything else than the abstractions to "build". (in a static type sense)
• we want the generated code to be agnostic from any given serialization format/library
• we want to avoid using reflection as much as possible (perf, side effects...)

This is why models implement the auto-serialization pattern (they describe how to serialize/deserialize themselves)