[Clam-devel] connecting ports
Pau Arumi
parumi at iua.upf.edu
Tue Jun 5 11:41:02 PDT 2007
En/na Pau Arumi ha escrit:
> En/na Xavier Amatriain ha escrit:
>
>>> By the way from what I can tell all of the ports have been published
>>> with free text names written in the actual classes. This is fairly
>>> poor style as it makes it difficult to retrieve these names later. It
>>> would be better to replace these free text names with constants or
>>> macros that are defined in either a single constants file or in a
>>> single constants file per package.
>
> in the lines of xavier's comment: note that processings get
> registered to a factory in each own cxx file. this allow us to
> define modules just by moving cxx files around, and eventually will
> make the framework easy to extend (when runtime plugins are here).
> so a module-wise definitions is something we try to avoid for that
> reason.
>
>> Saying that existing code is "farily poor style" in your first
>> contribution to the list is not the best of styles either ;)
>> Nevertheless, I agree that keyword-based registration is very
>> error-prone and I have experienced that myself. However constants or
>> macros on a single file or per package are not a very maintainable
>> solution, especially if the repository is more or less dynamic. I'd
>> prefer to keep this port registration on each processing class but add
>> some sort of static compile-time check. The only way I can think of
>> doing this is with macros though.
>
> i'm trying to think what kind of compile-time check could be done
> and i can't come up with anything. ideas?
>
> ah, maybe you are thinking on multiple constructors, each with its
> string registration, right?
>
> this should be refactored using only one contructor like in this
> example:
> http://clam.iua.upf.edu/wikis/clam/index.php/Creating_a_minimal_processing_object
>
oh, i forgot: the current ports and controls naming convention is
_horrible_. actually it is completely lacking a convention. :-(
now that at least greg and hernan will be doing processings i think
now it's a good time to fix this. any convention proposal?
pau
More information about the clam-devel
mailing list