Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

> I believe QFJ is only dependent on generated field definitions. Do you
> manually maintain the C++/Fields.h file? Is that where the C++ Session
> gets it's field definitions rather than the generated field  
> definitions?

Yes, the messages are decoupled, the fields are not.  It's not really  
been much of a problem though since when using non typesafe methods  
the messages don't care what the field is as long as the number and  
type are correct.  I guess it is conceivable future versions of fix  
could change the names or types of the core session fields, but I  
don't think it's very likely.   Theoretically this could be decoupled  
as well, though if any of those fields are missing you don't really  
have a FIX session anymore.  Perhaps that would be a legitimate thing  
to do if you plan on using another transport as made possible by FIX  
5.0.

> I can't speak for Alvin, but I've been in several situations where
> I've needed to map domain objects to multiple versions of FIX
> and vice versa.

Oh yeah, me too.  In those situations there's a choice about whether  
to use compile time type safety or use dynamic logic.  Using type  
safety requires some more coding, but you have the benefits of the  
compiler letting you know when something is wrong.  Dynamic code  
doesn't give you that, but it allows you to create more compact code  
by allowing you to share.  I'm not really sure how you can get both  
those benefits at the same time.  Classic case of dynamic vs compile  
time type safety.

> My impression was that Alvin didn't want to give up all type safety,
> but wanted a message representation with more abstractions for common
> aspects of the currently generated message classes. Personally, I
> would just use the message objects directly as you've suggested.

Yeah, I think so to, I'm just not sure how that would be  
accomplished.  Perhaps an example would be helpful.  The problem is  
of course that messages change pretty significantly between versions  
sometimes.  Fields get added, removed, their type changes, groups are  
added, groups are modified etc. etc.

Groups are actually a case where you can take advantage of some  
sharing.  If groups have not significantly changed between versions,  
their is no reason you cannot call addGroup on a FIX.4.2 messages or  
a FIX.4.4 message with the same generated group object.  Making  
components into objects might be helpful in this regard as well.