September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu wrote:
> Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o)
One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally.
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu wrote:
> Ary Borenszweig wrote:
>> - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same.
>
> Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o)
>
> One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally.
I agree. Sorry tipsters. I think head/toe has one established thing and one cutesy. Tip/toe has two cutesies. An unwritten (or perhaps actually written) rule of good humor is that you shouldn't make a double pun. They somehow don't add to double effect.
Andrei
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "Walter Bright" wrote
> Andrei Alexandrescu wrote:
>> Ary Borenszweig wrote:
>>> - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same.
>>
>> Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
>
> I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
I allow removal during foreach in dcollections. However, it is done by the opApply function at the request of the delegate (I pass in a ref boolean).
I don't think this method violates the foreach contract.
I use this when I'm iterating over a container trying to decide whether elements should be removed. If you don't allow this, then either you must use an iterator/range model, or build a separate list of elements to delete once you have exited the foreach loop.
Using this model, I can do things like O(n) traverse and remove from an array.
-Steve
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu Wrote:
> Bill Baxter wrote:
> > On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >> Pablo Ripolles wrote:
> >>> What about "isDone"?
> >> isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
> >
> > Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty.
> >
> > Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous.
> >
> > So I agree. Stick the "is" in there.
>
> Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge.
>
> Andrei
>
> P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft".
So, what about "aft" instead of "tip"?
"head"/"aft" it's not that bad, is it?
Cheers!
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | Leandro Lucarella Wrote:
> Andrei Alexandrescu, el 12 de septiembre a las 09:39 me escribiste:
> > Pablo Ripolles wrote:
> > >What about "isDone"?
> >
> > isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
>
> I much prefer done, because is shorter, and, well, maybe because I hate CamelCase too ;)
I do not like it either, we already have it though. I definitely prefer CamelCase than inconsistency.
Cheers!
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | Leandro Lucarella Wrote:
> Andrei Alexandrescu, el 12 de septiembre a las 09:39 me escribiste:
> > Pablo Ripolles wrote:
> > >What about "isDone"?
> >
> > isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says.
>
> I much prefer done, because is shorter, and, well, maybe because I hate CamelCase too ;)
I do not like it either, we already have it though. I definitely prefer CamelCase than inconsistency.
Cheers!
|
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pablo Ripolles | According to http://en.wikipedia.org/wiki/Aft The opposite of aft is forward, pronounced "forrard" for some reason. Not good I think. I see nothing wrong with head/foot. There's "head of a bed / foot of a bed" so it is not the case that these words always refer to people or that there's always more than one foot. ---bb On Sat, Sep 13, 2008 at 7:12 AM, Pablo Ripolles <in-call@gmx.net> wrote: > Andrei Alexandrescu Wrote: > >> Bill Baxter wrote: >> > On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: >> >> Pablo Ripolles wrote: >> >>> What about "isDone"? >> >> isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says. >> > >> > Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. >> > >> > Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. >> > >> > So I agree. Stick the "is" in there. >> >> Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. >> >> Andrei >> >> P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet. > > A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft". > > So, what about "aft" instead of "tip"? > > "head"/"aft" it's not that bad, is it? > > Cheers! > |
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter Wrote: > According to http://en.wikipedia.org/wiki/Aft > The opposite of aft is forward, pronounced "forrard" for some reason. > Not good I think. Well, those are the adjective forms. I was thinking about the aft of an airplane... > > I see nothing wrong with head/foot. > There's "head of a bed / foot of a bed" so it is not the case that > these words always refer to people or that > there's always more than one foot. Ok, that sounds more convincing than "head"/"toe", that's for sure. > > ---bb > > On Sat, Sep 13, 2008 at 7:12 AM, Pablo Ripolles <in-call@gmx.net> wrote: > > Andrei Alexandrescu Wrote: > > > >> Bill Baxter wrote: > >> > On Fri, Sep 12, 2008 at 11:39 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > >> >> Pablo Ripolles wrote: > >> >>> What about "isDone"? > >> >> isDone is great, I just wanted to keep the one-word streak going. Let's see what everyone else says. > >> > > >> > Hmm. std.algorithm does have an "isSorted" function. So I guess I agree it would be more consistent if you call it isDone or isEmpty. > >> > > >> > Or rename "isSorted" to "sorted". :-) But then you have to face the consequences later when you want to have a predicate that is ambiguous without the "is". Probably a lot of noun predicates are in that category -- i.e. checking isSomeNoun(x). Like "isRange(x)" to see if x is a range. That would have to just become "range(x)" which is a bit ambiguous. > >> > > >> > So I agree. Stick the "is" in there. > >> > >> Thing is, people will call isSorted much less often than (isD|d)one. In std.algorithm clearly the one-word paradigm can't scale. But for a handful of heavily-used names I'd be willing to take the Pepsi challenge. > >> > >> Andrei > >> > >> P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet. > > > > A perhaps more aeronautical term but short and nice as an alternative to "tip" might be "aft". > > > > So, what about "aft" instead of "tip"? > > > > "head"/"aft" it's not that bad, is it? > > > > Cheers! > > |
September 12, 2008 Re: Revised RFC on range design for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sat, Sep 13, 2008 at 5:11 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > Walter Bright wrote: >> >> Andrei Alexandrescu wrote: >>> >>> Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o) >> >> One consideration when selecting names is how it would interact with google. One advantage to head/toe is there is already head/tail when thinking of a list, and head/toe would fit into that naturally. > > I agree. Sorry tipsters. I think head/toe has one established thing and one cutesy. Tip/toe has two cutesies. An unwritten (or perhaps actually written) rule of good humor is that you shouldn't make a double pun. They somehow don't add to double effect. > > Andrei > Head / foot! No cutesie == even better! --bb |
Copyright © 1999-2021 by the D Language Foundation