On 1/3/2011 10:05 AM, Louis LaBrunda wrote:
> Hi Jimmie,
>
> I implemented part of the FIX protocol as part of one of my projects a
> while ago.  I made very few classes.  The fields mostly map to simple
> Smalltalk classes like strings, ints, decimals, data and times.  Some
> fields are compound fields in that they contain other fields and are
> repeated in groups.
>
> I did not make a class for each FIX message.  I used dictionaries to map
> what fields were expected in each FIX message.  I mapped the FIX number
> based field names to symbols that I made up that made sense to me and
> matched the FIX name for the field.  This made for fairly simple code to
> parse/print FIX messages to and from my FIX message class.  The data is
> stored in dictionaries with my symbols as keys and the Smalltalk value of
> the FIX field as the value in the dictionary.
>
> This may not seem like good Smalltalk practice but I found that I wasn't
> really interested in doing anything with the FIX classes other than reading
> in FIX messages (data) and sending out FIX messages.  For working with the
> data, I had other classes the matched what the system was doing.  This
> often involved getting/sending much of the same data to/from another system
> that had its own message format.
>
> In that case I have basically the same data in a whole bunch of classes
> that match say a non FIX message format and an equal number of classes that
> match the FIX format.  Which one should you use to work with the data
> within the system?  So, on both sides I have simple classes that basically
> just move the field data to and from dictionaries by parsing or printing
> the values in the correct format.
>
> This made for some less than pretty code like:
>
> 	asc := msg at: #AccountSourceCode.
>
> instead of:
>
> 	asc := msg accountSourceCode.
>
> but it allowed for moving large numbers of fields from one message format
> to another with a loop that ran a dictionary that had matching symbolic
> field names for each message format.
>
> 	orderedCollectionOfFieldsToCopy do: [:f | | fixSymbol |
> 		fixSymbol := dictionaryOfCorrespondingFields at: f.
> 		fixMessage at: f put: (nonFixData at: fixSymbol).
> 	].
>
> Again, I don't know if this is in the best tradition of Smalltalk but in my
> multi message format environment, it seemed best.
>
> Lou

Hello Lou,

I don't think any of that sounds unreasonable. I just knew I wasn't 
wanting to create 1100 classes for the field types and the message 
types. I have been looking at the field types in the documentation and 
it looked reasonable to do exactly what you said, and I had planned on 
doing similarly. But I hadn't quite gotten to looking at doing similarly 
for the message types. I will take a look at that. The more that I can 
automate, the faster I can get it working and spend my time on more 
interesting problems. And like you say it is easier to add or move to 
other versions. I know my current need is for version 4.4. But I don't 
what other brokers or other the future requirements will be. It is nice 
be agile.

I think this is somewhat the simplest thing that could possibly work. If 
performance is insufficient or any optimization is required, it could 
then be done on a message by message, or field by field basis and still 
maintain a working system.

Thanks for sharing your experience and advise.

Jimmie