I don't think chaining array methods is a big deal since for the vast majority of the time performance doesn't matter. If its hot code then I can see it being a concern, but the advice given in this article is not generally applicable in my honest opinion.
We wouldn't have to worry about it at all, ever, if they introduced them properly, as iterator/stream adapters, and not one-off map(this:Array, fn): Array functions.
sort isn't a streaming/iterating operation, it's a collection operation. So if you have a stream going, it would make sense to sort on insertion into collection. Something like iter.sort(): Array or iter.sortInto(Array): void
Which means it needs to allocate the whole range, as an internal implementation.
I feel like whatever optimizations you can get out of hiding that implementation (Are there any, even?) are outweighed by the better decisions the developer will make when you shove this information in their face.
It isn't hidden, it won't compile if the range doesn't provide the needed operations. The simpilist solution is to call .array() before the call to sort.
I don't think chaining array methods is a big deal since for the vast majority of the time performance doesn't matter. If its hot code then I can see it being a concern, but the advice given in this article is not generally applicable in my honest opinion.
We wouldn't have to worry about it at all, ever, if they introduced them properly, as iterator/stream adapters, and not one-off
map(this:Array, fn): Array
functions.Exactly, D lazily operates over the elements and only needs to be eager for certain algorithms like sort.
sort
isn't a streaming/iterating operation, it's a collection operation. So if you have a stream going, it would make sense to sort on insertion into collection. Something likeiter.sort(): Array
oriter.sortInto(Array): void
D does an in place sort, so the range needs swap and random access. But yes, it isn't a stream.
Which means it needs to allocate the whole range, as an internal implementation.
I feel like whatever optimizations you can get out of hiding that implementation (Are there any, even?) are outweighed by the better decisions the developer will make when you shove this information in their face.
It isn't hidden, it won't compile if the range doesn't provide the needed operations. The simpilist solution is to call .array() before the call to sort.
That sounds awesome...
Are we talking about Dlang? :v
Yes
My Case for D
Jesse Phillips
Aw yiss, get that D!
Homegirl on a mission.
Also: Oh no, this competes with Rust in a number of usecases, better say bad things about it all around just in case.
Also: Vector operations look sweet.
Yes, that's right. You definitely shouldn't be bothered too much by these nuances because they're too negligible to even notice.
I could say that the point of this article is pretty much just to serve as a heads-up.