July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jthr4a$3f3$1@digitalmars.com... > > I swear I'd just call it "range". > > Andrei > Sure, why not. http://d.puremagic.com/issues/show_bug.cgi?id=8371 |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | >
> Given:
>
> @property int delegate() foo(){ ... }
> @property int bar(){ ... }
> int baz(){ ... }
>
> foo(); // calls the delegate.
> bar(); // illegal
> baz; // ok, call baz
>
> dmd -property gets every single one of these wrong. -property does _not_
> enforce @property semantics. It only adds a silly rule that was never
> part of the @property design. I am astonished that it made it into the
> compiler.
+1
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, July 10, 2012 22:04:17 Timon Gehr wrote: > @property int delegate() foo(){ ... } > @property int bar(){ ... } > int baz(){ ... } > > foo(); // calls the delegate. > bar(); // illegal > baz; // ok, call baz > > dmd -property gets every single one of these wrong. -property does _not_ enforce @property semantics. The current implementation of -property is horribly broken: http://d.puremagic.com/issues/show_bug.cgi?id=4183 http://d.puremagic.com/issues/show_bug.cgi?id=8162 It's not actually enforcing what it's supposed to enforce, and it needs to be fixed. - Jonathan M Davis |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote:
> Second, it would be much easier if it would be possible to better name these ranges, something like interfaces but without polymorphism. This as been mentioned several times before.
They're templated types. They have to be templated types. And since they're templated types, better names do you no good whatsoever as far as declaring a variable goes. You'll _never_ be able to do something like
NiceName range;
NiceName will always be templated. The _closest_ that you get is with Voldemort types. Since they're templated as part of the function that they're in rather than separately, they end up with names such as Result or FilteredRange, but you couldn't do
FilteredRange range;
because that type depends on its outer scope (in this case, filter). You'd _still_ have to use typeof or ReturnType if you need to declare such a variable without directly assigning it (in which case, you can use auto). And if you have a separate range type rather than a Voldemort Type, you end up with stuff like Until!("a == b", string, dchar). The templated nature of ranges makes it impossible to have friendly names which you can use to simply declare variables of a particular range type. auto, ReturnType, and typeof are required tools for dealing with templated types like this.
- Jonathan M Davis
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Jacob Carlborg , dans le message (digitalmars.D:171725), a écrit :
>> To make the best implementation would require to know how the String context works.
>>
> String is a wrapper around str.array.Appender.
Then, if the purpose is to make the code efficient, I would use the loop and append everything to the result without creating the params array, and even without creating the string p. Appender is made to append everything directly to it efficiently.
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.249.1341951069.31962.digitalmars-d@puremagic.com... > On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote: >> Second, it would be much easier if it would be possible to better name these ranges, something like interfaces but without polymorphism. This as been mentioned several times before. > > They're templated types. They have to be templated types. And since > they're > templated types, better names do you no good whatsoever as far as > declaring a > variable goes. You'll _never_ be able to do something like > > NiceName range; > This isn't really true. You can still in some cases the type relative to some other type. (warning: old code, may not compile any more) Sure, you can use auto and typeof, but that doesn't make it clearer. struct SubSequences(R) { R r; R s; Take!R c; int n; this(R r) { this.r = r; s = r; n = 0; c = take(r, 1); popFront(); } void popFront() { c.popFront(); if (c.empty) { c = take(r, ++n); s.popFront(); } } Take!R front() { return c; } bool empty() { return s.empty; } typeof(this) save() { return this; } }; SubSequences!R subSequences(R)(R r) { return SubSequences!R(r); } |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Jacob Carlborg , dans le message (digitalmars.D:171769), a écrit :
> On 2012-07-10 20:04, Andrei Alexandrescu wrote:
>
>> Then store an array. "No one's put a gun to yer head." http://youtu.be/CB1Pij54gTw?t=2m29s
>
> That's what I'm doing.
>
And that's what you should do. Algorithm are not made to be stored in struct or class instance. You could use InputRange(E) and friends to do that, but that's often not optimal. Algorithm are here to do their job and output non-lazy result in the end.
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tobias Pankrath | On 11-Jul-12 00:07, Tobias Pankrath wrote: >> >> Given: >> >> @property int delegate() foo(){ ... } >> @property int bar(){ ... } >> int baz(){ ... } >> >> foo(); // calls the delegate. >> bar(); // illegal >> baz; // ok, call baz >> >> dmd -property gets every single one of these wrong. -property does _not_ >> enforce @property semantics. It only adds a silly rule that was never >> part of the @property design. I am astonished that it made it into the >> compiler. > > +1 Same here. Still no idea what they were smoking at the time. -- Dmitry Olshansky |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christophe Travert | On 2012-07-10 22:13, Christophe Travert wrote: > Then, if the purpose is to make the code efficient, I would use the loop > and append everything to the result without creating the params array, > and even without creating the string p. Appender is made to append > everything directly to it efficiently. Yeah, I've been thinking about doing that more. -- /Jacob Carlborg |
July 11, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 07/10/2012 10:48 AM, Simen Kjaeraas wrote: > On Tue, 10 Jul 2012 16:15:09 +0200, Jacob Carlborg <doob@me.com> wrote: >> How do you store your ranges in a struct or class? Most of them are >> voldemort types. > > Well, there is std.range.inputRangeObject, but as the name indicates As the name "misleads"... :) >, it's > only an input range. ... it can be used as any one of the non-OutputRanges: import std.algorithm; import std.range; import std.stdio; void main() { int[] a1 = [1, 2, 3]; ForwardRange!int r1 = inputRangeObject(map!"2 * a"(a1)); ForwardRange!int r2 = inputRangeObject(map!"a ^^ 2"(a1)); auto a2 = [r1, r2]; writeln(a2); } Replace ForwardRange!int above with any other non-OutputRange, and as long as the input to inputRangeObject() is compatible, it will work. (static if magic). Ali |
Copyright © 1999-2021 by the D Language Foundation