Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type declarations (structs) #28

Closed
kengorab opened this issue Jul 14, 2019 · 0 comments
Closed

Type declarations (structs) #28

kengorab opened this issue Jul 14, 2019 · 0 comments

Comments

@kengorab
Copy link
Owner

kengorab commented Jul 14, 2019

Spec

I should be able to declare struct types, which are named and have any number of typed fields. Type names must begin with a capital letter.

type Person {
  name: String,
  age: Int,
  favoriteColor: Color
}

// To be handled in another issue
type Color enum {
  Blue,
  Purple,
  Green,
  Red,
  Other
}

To create instances of a type, a "constructor function" will be made accessible, which has an argument for each field.

type Person {
  name: String,
  age: Int
}

val ken = Person(name: "Ken", age: 27)

Questions

How to handle Optional fields in a constructor?

If there's a type declaration like

type Person {
  name: String,
  favoriteColor: Color?
}

what should the constructor function look like? Should that field be omittable in the constructor function, the absence of which should denote an empty Optional? What happens if the type declaration is

type Person {
  name: String,
  favoriteColor: Color?,
  age: Int
}

with an Optional in between two non-Optional fields? Should Optional fields always be bubbled down to the end of the declaration? Should constructor functions work a little bit differently and not require the order of the named arguments to match up (I dislike this)? Should there be an explicit None type, and it should have to be passed for empty optionals (I like this one the best)?

Should we support default field values?

This one might wait until #29 is done, but I'm imagining a situation like

type Person {
  name: String = "Ken",
  age: Int
}

where the name field is pre-filled with a default value. Should there be 2 constructor functions generated?

func Person(name: String, age: Int): Person
func Person(age: Int): Person

Should we not have a "constructor function" and instead use something else?

type Person {
  name: String,
  age: Int
}

val ken: Person = {
  name: "Ken",
  age: 27
}

This option is a little better, because it solves the problems above. Something to think about when the time comes.

Should we have some mechanism for methods?

type Person {
  fields {
    name: String,
    age: Int
  }

  func toString() = self.name + ": " + self.age

  static func incrAge(p: Person) = { ...p, age: p.age + 1 }
}

In this model, the previous example would be a shorthand for when we don't want to attach specific instance methods to a struct; all we'd want in that case is a simple data class or container. In other words,

// This definition is a shorthand for ...
type Person {
  name: String,
  age: Int
}

// ... this more verbose representation
type Person {
  fields {
    name: String,
    age: Int
  }
}
@kengorab kengorab created this issue from a note in Language Core (To Do) Jul 14, 2019
@kengorab kengorab moved this from To Do to In Progress in Language Core Jul 30, 2019
@kengorab kengorab moved this from In Progress to To Do in Language Core Aug 3, 2019
@kengorab kengorab moved this from To Do to In Progress in Language Core Sep 2, 2019
This was referenced Sep 8, 2019
@kengorab kengorab moved this from In Progress to Done in Language Core Sep 17, 2019
This was referenced Sep 17, 2019
@kengorab kengorab moved this from Done to New Done in Language Core May 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant