Why can't you use a outer constructor to apply default values for the type?
type MyType field1 field2 field3 field4 field5 end MyType() = MyType(default1, default2, default3, default4, default5) Then you can instantiate an instance with MyType() and then just edit the fields you want different. m = MyType() m.field3 = 55 m.field5 = "abc" On Sunday, December 22, 2013 12:39:17 PM UTC+2, Marcus Urban wrote: > > The reason that the inner constructor is written that way is to avoid > having to assign values to every field when constructing a new instance. > Since default values are not implemented, that approach will not work. > > I am trying to avoid the situation of having a composite type with, say, > 20 fields, many of which have are reasonable defaults, and having to write > m = myType(3, "Triangle", …, 2.5) where the ellipses represents a sequence > of 17 values. (Is the 15th parameter the month of George Washington's birth > or the high temperature in Alaska in 1945?) > > > On Saturday, December 21, 2013 9:10:36 AM UTC-6, John Myles White wrote: >> >> Assigning default values to fields of a composite type is not yet >> supported. >> >> Your inner constructor is also a little un-Julian, since `MyType() = >> new()` doesn’t assign any values to those fields. >> >> — John >> >> On Dec 21, 2013, at 4:37 AM, Marcus Urban <[email protected]> wrote: >> >> > I am a little confused about constructing composite types. Given the >> definition >> > >> > type MyType >> > x::Int >> > y::Int = 6 >> > MyType() = new() >> > end >> > >> > an instance of MyType can be created using >> > >> > m = MyType() >> > >> > At that point, m.x acts as expected --- I can assign to it, read its >> value, and so forth. However, attempting to access m.y produces an error >> that MyType has no field y. Based on another post, I gather that my attempt >> to provide a value to m.y in this manner is not allowed If that's the case, >> what exactly is the effect of "y::Int = 6" If this part of the code is >> completely ignored, it would be really nice if the system let me know since >> initializing fields in this way is common in many languages. >> > >> > Also, I gather that a workaround is to use a constructor that takes >> named arguments. Is that still the recommended way? With just two fields, >> things are not difficult, but if the type has 20, calling a constructor >> with 20 positional arguments would be difficult. >> > >> > >> >>
