Making it stick.

On DevHawk the discussion continues about objects and data. Herewith are some thoughts...

Objects are first and foremost for code organization. Computers could do their work just fine, thank you, without objects. And so if the "data" or "messages" or "documents" are not going to map to objects, then will we be better off?

I think the salient, yet somewhat conflicting, points include these:

• Objects are for code organization
• Commands, messages, and documents can be organized as objects
• Different languages have widely different implementations of "objects"
• Interoperability should not assume anything about a specific object model
• Still, mapping data exchanges into the objects of your language are desirable
• Therefore, attempt to model interoperable data exchanges as objects to the extent it will help you with your code organization

In addition to objects, the other code organization mechanism that will lessen your burden is pattern matching. The better pattern matching is integrated into your language, the less code you will have to write when passing semi-structured data around.

Erlang is a good example of a language that does not have "objects" per se, but Erlanf does have a very convenient pattern patching syntax for interprocess messages. Languages that have both objects and pattern matching are even better off.