Hi Ray, You're probably the first person to make this observation. I can see your point, and I don't really have a strong argument or opinion, really--the main reason it's sorted is probably because it looks nicer--at least if I did write that code, that would have been my reasoning.
If you're up for it, you could change it to create a set and submit a pull request. No guarantees it gets accepted, but the likelihood increases significantly over not submitting one. :-) Cheers, Kevin On Sunday, December 27, 2015, Ray Toal <[email protected]> wrote: > 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]> 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? >>>>>> >>>>>> >>>
