Sure. That avoids unnecessarily copying the array. On Mon, Dec 28, 2015 at 10:51 AM, Ismael Venegas Castelló < [email protected]> wrote:
> 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]> >> 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]> 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? >>>>>>>>> >>>>>>>>> >>>>>> >>
