Stefan, wouldn't using `sort!` instead of `sort` be better here in this case?:
subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string) subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)), by=string) El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski escribió: > > No, please don't spend time on this. We're not going to change this to > return a heavyweight data structure like a Set when a simple structure like > and Array will do. In mathematics sets are simpler than ordered > collections, but in programming languages the relationship is reversed. In > general data structures like Set are only used when they are necessary, > such as when you need O(1) checking for inclusion. Since there's no such > need here, an array is simpler and better. > > On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire <[email protected] > <javascript:>> wrote: > >> 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] <javascript:>> >> 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? >>>>>>>> >>>>>>>> >>>>> >
