On Apr 9, 4:54*pm, RickB <rbiel...@xxxxxx> wrote:
| Quote: |  | |
|
>
> I can't see the page you refer to but I also don't see how knowing
> the number of records already processed (which your function can
> count itself pretty easily) can tell you how far along you are.
> Knowing how many are left would require that you somehow know how
> many objects will ultimately be processed. *Such information is, in
> most cases I can think of, simply not available. *It's like asking
> how many words I will type today. *Moreover, this 'count' could be
> different at every step in the pipeline. *Maintenance of all these
> counts represents an amount of overhead I'd just as soon not have
> every application I write saddled with. *Especially when I can't
> think of even one practical use much less enough uses to consider
> that it might possibly be justifiable.- Hide quoted text -
>
| |
| | |
You're misreading me.
Clearly, knowing how many records are yet to come in the future is not
something that can be know - but that's not what I was suggesting.
Rather I was suggesting that a count be kept of how many records have
been processed thus far, through the current pipeline step.
This would be exactly analogous the the NR variable in awk (another
record processing language).
Granted, if you've not much file or log processing in powershell then
I agree the usefulness of this feature may not be obvious to you.
And as to the overhead of maintaining this count - it's a single
integer which the pipeline could increment every time it calls
ProcessRecord. By any measure that cant be considered too expensive
to maintain given all the other processing that goes on in a pipeline.