Module naming

[lpil]

Module naming

[lpil]

Given type specific functions are not required for decoding I think the encode_ prefix would be redundant- the second example you give could be this:

import gleam/jsone.{JsonValue}

pub fn encode_person(name: String, age: Int) -> JsonValue {
  jsone.object([
    tuple("name", jsone.string(name)),
    tuple("age", jsone.int(age))
  ])
  |> jsone.encode
}

This is the most concise, has unambiguous module names without renaming, and requires only a single module import.

[rjdellecese]

I'm persuaded—I like that better. Reopening to track as a task.

[rjdellecese]

Thank you for the feedback, @lpil!

I hear you, and had also wondered the same thing. I agree that the usage in your example feels a bit awkward.

The main reason I chose this module naming structure was that I thought the encoding functions would feel better to use this way. The usage I envisioned was like so:

import gleam/jsone/encode.{encode_json, JsonValue}

pub fn encode_person(name: String, age: Int) -> JsonValue {
  encode.object([
    tuple("name", encode.string(name)),
    tuple("age", encode.int(age))
  ])
  |> encode_json
}

So I guess that would be in contrast to something like this:

import gleam/jsone.{JsonValue}

pub fn encode_person(name: String, age: Int) -> JsonValue {
  jsone.encode_object([
    tuple("name", jsone.encode_string(name)),
    tuple("age", jsone.encode_int(age))
  ])
  |> jsone.encode
}

I still think I might like the former a little better... if you wanted to make it really clear what kind of data you were encoding, you could always alias the import, e.g.

import gleam/jsone/encode.{encode_json, JsonValue} as jsone_encode

pub fn encode_person(name: String, age: Int) -> JsonValue {
  jsone_encode.object([
    tuple("name", jsone_encode.string(name)),
    tuple("age", jsone_encode.int(age))
  ])
  |> encode_json
}

But I'll keep thinking about it!

Thank you again for the input! :)