[Debtags-devel] Hello, and a few improved tag descriptions

[Enrico Zini]

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 03, 2005 at 02:09:40PM +0200, Benjamin Mesing wrote:

> > That would mean that a class wouldn't need to be a consumer to get
> > packages, and that many of its methods could be fed packages by some
> > producer.
> I am fan of C++ and I also appreciate the possibility to use functors.
> But in my opinion functors are most usefull when providing algorithms.
> Implementing an interface is far more expressive than overloading the
> operator(). Others might disagree here...=20
[..]
> That said, I summarize myy opinion in going with Mike: Be carefull with
> functors.
> I've attached an article discussing the limitations of adapters and
> binders.

Interesting, thanks Benjamin!  I've read the paper with big interest,
and your feedback and Mike's have made me think more about what I want
to do.

I think the main question I have is this one:

   Is the current interface the best possible you can think of, or can
   you think of something better?


And this thinking about functors finally gives me an opportunity to come
out (finally, after years) with my design doubts:

 - One is this: "if the C++ standard is operator(), maybe I should
   rename consume() to that".  But then I realised that operator() is
   best used for adaptors, and consume should instead be renamed to
   something that actually tells what the object is doing, such as
   "addItem", "filterItem", "printItem" or such.  This would however
   complicate the library by requiring to use adapters every time I now
   just put the normal class.

 - I'm also tired of the long syntax used to create TagcollFilters and I
   was wondering if something could have been done without the need of
   implementing virtual destructors and constructors to propagate the
   parent's constructor with a consumer argument.

 - I've also been wondering if the output(TagcollConsumer&) interface of
   TagcollCollection could have been designed in a more generic way

 - But then, what I should really do is provide iterators to
   TagcollCollections.  That way they could be made to fit into a more
   generic framework and allow to process them without resorting to
   Consumers and Filters.

   However, how do I design such iterators?
  =20
   TagcollConsumer now has 4 'consume' methods, of which 2 with a
   default implementation:

        // Process an untagged item
        virtual void consume(const ITEM& item) =3D 0;
        // Process a tagged item, with its tags
        virtual void consume(const ITEM& item, const OpSet<TAG>& tags) =3D =
0;
        // Process a set of items, all with no tags
        virtual void consume(const OpSet<ITEM>& items);
        // Process a set of items identically tagged, with their tags
        virtual void consume(const OpSet<ITEM>& items, const OpSet<TAG>& ta=
gs);

   This means that when iterating, we're either iterating a
      pair<ITEM, OpSet<TAG> > or a
      pair<OpSet<ITEM>, OpSet<TAG> >.

   Does that mean 2 different sets of iterators?
  =20
   And how unefficient would it be, since I'd possibly have to construct
   the pairs if the TaggedCollection implementation is structured
   differently?


But again, the real question that I have is this one:

   Is the current interface the best possible you can think of, or can
   you think of something better?


If you all have any idea, please speak out: I'd love to have more brains
involved in design.


> P.S. 40kB seems a strong limitation for this mailing list

Doh!  I didn't even remember there was a limit.  I set it to 1000Kb now,
I can increase it if needed: limits are useful to avoid mistakes to
cause trouble, not to cause burden on posters.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@enricozini.org>

--AqsLC8rIMeq19msA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCoFl99LSwzHl+v6sRAiQfAJ48WNtRsiI/KXCaI++2NSRgY4gP/QCeLO4p
uub6ffOwfRjOWVw5zmv9nNw=
=12WC
-----END PGP SIGNATURE-----

--AqsLC8rIMeq19msA--