I'm sure the order won't ever change, but I'd still find it odd if the documentation of subtypes were to say
"Returns a list of subtypes, sorted by the name of the subtype" because, well, what about namespaces? What about all sorts of Unicode collation definitions that would have to be a part of such a definition? Yes, as much as I would like to just assert that the result of calling subtypes on Type produces the array [DataType, TypeConstructor, Union] it's just not supposed to be an array, even if today we can guarantee that the array will be sorted, and it is ridiculously unlikely to change. I just think of unordered collections as sets. I don't think anyone would or should ever write code that takes advantage of the fact that this array is sorted, though. :) Thanks for the responses Ray On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote: > > Thanks for looking and posting (I've been on my phone). I think I might > have written that code, actually. ;-) > > Cheers! > Kevin > > On Sunday, December 27, 2015, Ismael VC <[email protected] <javascript:>> > wrote: > >> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the >> same versions in julia box, and the output is deterministically sorted, It >> seems this has been the way it works for some time now, then I looked at >> the code and it’s indeed sorted (should have done that first! :P ): >> >> - http://git.io/vEXL9 >> >> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string) >> subtypes(x::DataType) = subtypes(Main, x) >> >> I would expect a very good reason in order to justify a change for this >> now. >> >> >> 2015-12-27 18:06 GMT-06:00 Kevin Squire >> >>> 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ó 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? >>>>> >>>>> >>
