Ah, I didn't think about performance. I was simply thinking that sets make
more sense semantically when the order does not matter, and arrays or lists
make sense when the order does matter. I thought there would be no point in
using an array for unordered items, but it sounds like the point is
performance.
I was putting together some instructional materials on Julia for a class
and wanted to show off subtypes. I prefer writing demo code with asserts
rather than prints, so I thought about writing
@assert subtypes(Type) == [DataType, TypeConstructor, Union]
However this is not reliable because the order is actually arbitrary. So I
have to write
@assert Set(subtypes(Type)) == Set([DataType, TypeConstructor, Union])
which is ugly and would have been simpler if subtypes just returned a set
in the first place!
Granted this is a minor nitpick because no one writing _real_ code would
likely need to write a unit test asserting the value of the subtypes
collection. Even if they did, I suppose they could make sets themselves.
Anyway, it just strikes me as weird to use an ordered collection where no
order is implied. It's just yucky to me, but I will happily buy the
performance argument (and perhaps a simplicity one, too, since sets require
syntactic overhead as well!).
Thanks
Ray
On Saturday, December 26, 2015 at 9:10:38 PM UTC-8, Kevin Squire wrote:
>
>
>
> On Saturday, December 26, 2015, Ray Toal <ray....@gmail.com <javascript:>>
> wrote:
>
>> I noticed that
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the
>> subtypes. If not, could the method have produced a Set instead?
>>
>>
> It could, but why? A set has a bit more overhead than an array, and for
> most types, the number of subtypes is small enough that sets wouldn't
> really offer any advantage.
>
> Is there something you want to do with the results that you think requires
> a set?
>
> Cheers,
> Kevin
>
