|Posted by KnightMare||PermalinkReply|
KnightMare <firstname.lastname@example.org> changed:
What |Removed |Added
--- Comment #12 from KnightMare <email@example.com> ---
(In reply to Andrei Alexandrescu from comment #11)
> I don't think it's wise to add HOFs of which predicates just negate that of other HOFs. I'm convinced that any programmer can be reasonably expected to figure negation out without problems, otherwise we're liable to experiments a la Perl/Ruby "unless" as a negation of "if". My understanding is that the usefulness of such is still a matter of debate and style differences within the respective communities.
> I'll close this, please reopen if there are qualitatively new arguments.
word "until" is doubt word for me (I am non English native)
when I hear "until noon" I am in doubt cuz it means "they will care something
before noon" or "when noon will come then they take care of it"
until accepts sentinel that don't needed for explicit predicate in most time
with explicit predicate that accepts 2 args it adds another doubt about arg
order: what 1st arg - element or sentinel?
for example I want sequence of fibonacci numbers less than 100
fibs.until!((a,b) => !(a<b))( 100 ).each!writeln;
// ^ element is 1st or 2nd? lets go to look docs
// ^ ^ when I have explicit predicate why I need
sentinel as arg at all? I can put it as literal to predicate
// ^ condition is negate of my wish. yes I can negate
condition for IF/FOR/WHILE cases but with doubts for UNTIL its make me crazy. I
should write some test in REPL just to make sure that I am not failed with such
simple condition. why that?
totally its too complicated for such simple thing:
fibs.takeWhile!(e => e<100).each!writeln;
or even shorter
and we have already take, takeOne, takeNone, takeExactly. why do not just to add this one to set of same named algos?
so please add takeWhile/skipWhile algos to library cuz its clear and shorter
and without_unnecessary_negate (haha?) and without_unclear (haha again?) args
another thing that I want to tell on the example of next comment
> Jonathan M Davis
> Closing it as "won't fix" would be more appropriate. We already have until, which does what takeWhile would do - it just has an arguably worse name. Is there something about until that does not fulfill what takeWhile would do? While I don't think that it existed when this issue was opened, there is now an overload for until that does not take a sentinel and AFAIK does exactly what takeWhile would do.
well, last sentence is wrong: "until" jast boomboom brains instead "takeWhile". see my arguments above.
imo u have some preset that makes you decide that only one name should exists
for things that somehow likely. well, turn around, u can see cars, people,
things they are all same but they are all are different.
its not a sin to have aliases for likely things or functions. people comes to D
from other langs, they fill more comfort with names to which they are
accustomed. and takeWhile and skipWhile is most useful names to enumerate
elements for true predicate. (python, .net...)
when u try find method like for such task i am sure u will type "dlang take
while" not "dlang until" cuz "until" is any f*king blog word. what u expect to
find with it?
if u like "until" then use it, but please don't prohibit things that more
comfortable to others.
and "until" and "takeWhile" and "skipWhile" and "drop" can coexists in one
library if u free your brain from some inexplicable preset.
just add aliases with right predicates to most useful algos and links such
aliases to each other in documentation when they are 100% same. "until" and
"takeWhile" is not same for 100% probably only for -60% (minus for negate
PS "skip" is more clear/pure name for "drop" cuz we are skipping element not droping it to somewhere (another range or ground floor) maybe for English native is same thing, but I dont know 100 meanings for one simple word.
PS2 "until" is still useful for non literal sentinel or with default implicit predicate