You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
}
}
The text was updated successfully, but these errors were encountered:
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.
To create instances of a type, a "constructor function" will be made accessible, which has an argument for each field.
Questions
How to handle
Optional
fields in a constructor?If there's a type declaration like
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
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
where the
name
field is pre-filled with a default value. Should there be 2 constructor functions generated?Should we not have a "constructor function" and instead use something else?
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?
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,
The text was updated successfully, but these errors were encountered: