Many Julia types are just 64 bits of data – Int, UInt, Float64. Should those all be a single type?
On Saturday, February 6, 2016, Uri Patish <[email protected]> wrote: > 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]> 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. >> >
