I agree that with the case of a string field my approach would be more exprensive memorywise, but this is not necessarily so in the general case. For example, having a type whose invariant is that it only holds integers within a certain range, and having different outer constructors for each range. In this example, the parametric type aproach would cost more bits.
Regarding your note on how types should be used, I tend to disagree. For example, in languages that support OOP and allow overloading, it is considered a bad practice to have two classes that are exactly alike, in order to differentiate between groups of instances. Even though Julia has multiple dispatch rather than single dispatch (traditional OOP), I don't think this should result in different design patterns. Uri On Saturday, February 6, 2016 at 4:41:57 PM UTC+2, Yichao Yu wrote: > > On Sat, Feb 6, 2016 at 8:31 AM, Uri Patish <[email protected] > <javascript:>> wrote: > > Yes, 'type A a::Int end' and 'type B a::Int end' should be just a single > > type. > > I think that's not the right understanding of (julia) types. There are > many more informations a type can carry other than the data layout and > depending on what you need those information for, they don't > necessarily have to live in the memory of the object. It will also be > a waste of memory to store these shared information in every types > since it will be exactly the same for all instances of the type. > > > > > Indeed you are right, in a second trial I've done the typealias solution > > didn't work as the second method definition overwrites the first. >
