Hi Ted,

I originally split the iterator functionality into to types - a generic field 
iterator and an address-field specific interator - simply to provide some 
clarity and enforce proper usage (e.g. address iterators for address fields, 
generic interators for the rest).

The original iterator type had extra logic for dealing with address type fields 
- state such as prefix, view type, and parsing fields with '/' having special 
significance. This required the user of the iterator to be careful to use the 
proper methods based on the semantics of the field being iterated over.  But 
there was no way to enforce correct usage based on the type of field being 
parsed.  One could easily pass say a username field to a function that expected 
to parse an address without any indication of the error.

Again, just my opinion.  I haven't worked on the dispatch codebase for awhile 
so this view may be out of date.

If combining the two types back into a generic type can help optimize the 
performance of iterators then that's more important.

Is it possible to provide compile-time checking to prevent using address field 
logic with non-address field instances (and maybe vice versa)?

-K


----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: dev@qpid.apache.org
> Sent: Wednesday, November 16, 2016 11:54:25 AM
> Subject: Dispatch Router Iterator changes
> 
> The iterator module in Dispatch Router is in need of some clean-up and
> re-factoring.  It has undergone several rounds of evolutionary extension
> and is resisting further extension (for support of multi-tenancy).
> 
> I propose the following change to the iterator module as a starting point.
> 
>     Remove the false hierarchy of "field" iterators and "address"
>     iterators.  In the process, shorten the names of all the methods to
>     be just "qd_iterator_<method>"
> 
> Opinions welcome,
> 
> -Ted
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to