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] <javascript:>> > 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. > > > > > >
