On 4/29/14, 4:09 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> On 4/29/14, 11:08 AM, bearophile wrote:
>>> In Phobos there are awkward names like walkLength
>>
>> Love it. -- Andrei
>
> The name like "walkLength" was chosen (by you?), instead of a more
> natural name like "length" (or even a nice, short, clean, readable,
> handy and easer to write name like "len" as in Python) to underline that
> walkLength could be O(n).

"length" was already taken, and it seemed unbecoming to have "len" describe the longer operation. I find "walkLength" awesomely suggestive. -- Andrei

On Tuesday, 29 April 2014 at 23:09:42 UTC, bearophile wrote:
> The name like "walkLength" was chosen (by you?), instead of a more natural name like "length" (or even a nice, short, clean, readable, handy and easer to write name like "len" as in Python) to underline that walkLength could be O(n).

I usually prefix such cases with "calc", e.g. calcLength / calc_length

On Tuesday, 29 April 2014 at 18:09:00 UTC, bearophile wrote:
> In Phobos there are awkward names like walkLength

walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well.

On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
> walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well.

Actually it isn't a good abstraction as it exposes implementation internals.

The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan).

"walk" indicates that you can use a visitor-pattern, thus it is a misleading name.

(Not that it matters.)

On Wednesday, 30 April 2014 at 11:20:40 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
>> walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well.
>
> Actually it isn't a good abstraction as it exposes implementation internals.
>
> The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan).
>
> "walk" indicates that you can use a visitor-pattern, thus it is a misleading name.
>
> (Not that it matters.)

For algorithms execution complexity is not a mere implementation detail. "walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach.

On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote:
> For algorithms execution complexity is not a mere implementation detail. "walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach.

For you maybe. For me the response is "walkLength???" WTF is that? Does this imply a length restricted forEach?

I've never seen "walk" or "traverse" being used for indicating O(n), it is usually used to indicate something you can utilize in order to traverse a data-structure. That's how the terms are used in CS.

"Walk" is an imperative. "walk length" indicates "walk the length of", not "calculate the length of".

But naming functions is often more difficult than writing the code. (not a joke)

On Wednesday, 30 April 2014 at 11:35:56 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote:
>> For algorithms execution complexity is not a mere implementation detail. "walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach.
>
> For you maybe. For me the response is "walkLength???" WTF is that? Does this imply a length restricted forEach?

And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) "walk" here implies iteration and iteration implies O(n).

On 4/30/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 4/29/14, 11:08 AM, bearophile wrote:
>> In Phobos there are awkward names like walkLength
>
> Love it. -- Andrei

std.algorithm.count also works with any input range, they can use that if they don't like walkLength. Unless it has some limitations? I can't think of any.

On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote:
> And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) "walk" here implies iteration and iteration implies O(n).

The common term is "count", "countNodes", "countElements" etc... Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations? I find fragmented libraries hard to use.

On 4/30/14, 4:20 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
>> walkLength is a really good name. Clear, concise, to the point. It's
>> not often that you can make such a short name that explains the
>> behaviour so well.
>
> Actually it isn't a good abstraction as it exposes implementation
> internals.
>
> The name should indicate what you get (the calculating of a result), not
> how the framework obtains it (sequential scan).

Making complexity an implementation detail is an antipattern. -- Andrei