Ray, thanks for the clarification--makes sense. In fact, for introspection
code like 'subtypes', performance is probably the wrong argument--it's
unlikely that it occurs in performance-critical code. I think it's really
that arrays are just simpler.
One aesthetic change I could imagine would be to have the results sorted
before returning, which would keep the same data structure, but solve your
problem, and present the subtypes in a way the user would likely find more
useful.
Ismael, it might be a little brittle to depend on the current order (unless
it's always sorted now).
Cheers,
Kevin
On Sunday, December 27, 2015, Ismael Venegas Castelló <
ismael.vc1...@gmail.com> wrote:
> You can just do:
>
> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>
> I just tested this:
>
> julia> @time for i in 1:1000
> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
> end
> 3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>
>
>
> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal escribió:
>>
>> 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?
>>
>>
