Structure of complex ex-OOP programs

2010-07-12 Thread Timothy Baldridge
Okay, I have a fairly complex app I'm thinking of converting to clojure as a way to learn how clojure works. Here's how the basic structure of the app works: 1) Load a SVG (XML) file and parse it into a format usable by the program (convert strings to numbers, etc) 2) Persist the in-memory

Re: Structure of complex ex-OOP programs

2010-07-12 Thread Nicolas Oury
1) would be more: - define a protocol for each kind of function (render, serialize...) - define a deftype/defrecord for each type of element, and make them extend the protocol It's not that different from 2. (protocol, as far as I understand, are multimethod whose dispatch function is the type

Re: Structure of complex ex-OOP programs

2010-07-12 Thread Moritz Ulrich
1. would be my favorite too. Multimethods are fine too, but may be a bit slow. 3. is the same as 2. while avoiding multimethods. On Mon, Jul 12, 2010 at 10:26 PM, Nicolas Oury nicolas.o...@gmail.com wrote: I would do for 1, but other would do differently I think. Good thing with a

Re: Structure of complex ex-OOP programs

2010-07-12 Thread raould
On Jul 12, 1:26 pm, Nicolas Oury nicolas.o...@gmail.com wrote: The right choice depends somehow of taste. chipping in two cents: try to predict what kinds of change your system needs to support, and use that to help choose a style. (a) fp style: easy to add new operations on a fixed set of