PATCH to make minicli use all KURIFilterPlugins

[Dawit A.]

On Tuesday 29 October 2002 07:03, Neil Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday October 29, 2002 03:20, David Faure wrote:
> > I don't see the need for this redundant storing. Why not implement
> > plugins() (which should be called pluginNames() instead) in terms of
> > "iterate over m_lstPlugins and collect names"?
> > pluginNames() won't be called by all apps using the class, so the
> > additional memory storage isn't worth it.

I was going to suggest this same thing :)

> > OTOH I would still store the two lists as member variables in minicli,
> > so that it doesn't have to remove() in each call to parseLine() - which
> > is called for _every_ keypress!
>
> I don't see this as really being a problem as I doubt there will exist that
> many filters, and the idea of having every user of KURIFilter doing its
> own cache bothers me, but ultimately it's not important to me which end
> the cache is on.  

IMHO every bit you can save in these core classes matters.  If ten developers 
take the same approach on these kind of issues, you can easily end-up with a 
significant waste of resources at some point.  I think one should always 
design for the worst case scenario. Specially since one of the remaining work 
for the core is optimization in regards to speed as well as memory.

> I just want my apidocs.
:)

> So here it is your way.

It looks okay, however I still have reservation about this change as a whole.

With this change you are only barring a specific filter.  Anyone can 
create/rename/re-package these filters and minicli will easily be fooled into 
using them.  IMHO nothing short of a system/user-defined separation of such 
plugins will fix this issue and make things "sane".  But that is post 3.1 
work ; so I guess this can do for now.  Unless of course you are willing to 
hold off your patch for post-3.1.  I for example, have several patches 
pending for post-3.1.

Regards,
Dawit A.