On Apr 15, 3:36*am, MichaelL <goo...@xxxxxx> wrote:
| Quote: |  | |
|
> 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. | |
| | |
But even here, there must be a place to store it, meaning the integer
must be a property on some object associated with every single step in
every single pipeline of every user everywhere, just because you
don't
feel like adding a counter to the step where you happen to need
counts.
You could even create a step in your pipeline that attaches a
noteproperty
to each object with it's sequence. Then you would have it everywhere
without even having to maintain counters everywhere.
get-sourcedata|add-counter|all-my|other-steps|?{<criteria}|add-counter|
more-steps....
You could even sort your objects and know the original order unless
(as in my example) you updated the counter values by piping them thru
add-counter a second time.
Personally I'm in the process of developing a script that, under some
circumstances, might have a great many steps in progress at any given
time and I don't see anywhere in my system where such information
might
be an advantage to 'have at my fingertips'.
I know your examples were "meant to show behaviour, not usefullness"
but seeing as how I may need to incur the memory, performance, and
code
bloat of another property on every pipeline, I don't think it's
terribly out of line to ask for some real usefullness to the general
population of PS users.