markg added a comment.

  Based on the comment you made in it's 
logical that this commit won't make it as it currently is implemented.
  The using line is probably also not the best option if you want to keep the 
convenience functions, inheriting would be better. But then again, inheriting 
from an std container gives it's own issues (like no virtual destructor...)
    std::vector, for example, is not designed to be inherited and typically 
should not be inherited (very shaky design), as that will then be prone to this 
base pointer deletion issue (std::vector deliberately avoids a virtual 
destructor) in addition to clumsy object slicing issues if your derived class 
adds any new state.
  That kinda leaves me wondering how to proceed with this.
  Some options i can think of:
  1. Do nothing. Leave as is for now and the foreseeable time. No move 
  2. Go for the using line (as KFileItemVector) but with a 
"KFileItemVectorHelper" namespace that contains the current helper function. 
(or just the KIO:: namespace).
    1. In this case not deprecating the existing API before all other functions 
that currently use KFileItemList have a KFileItemVector counterpart
    2. Also put this under a compile time define (say -DUSE_KFILEITEMVECTOR) 
which means the code will be littered with #if statements, but maintains 
performance as it currently stands. Using this define would disable 
KFileItemList so that too would be under #if statements.
    3. This also allows for a more graceful transition as not everything has to 
be implemented at once. Once everything is implemented, add a whole slew of 
deprecated warnings to all KFileItemList uses.
    4. In KF6 simply remove all #if and end up with only KFileItemVector code 
  3. Something else?
  What's your opinion?

  R241 KIO


To: markg, dfaure
Cc: #frameworks, michaelh, ngraham

Reply via email to