I know my reply is a bit delayed but the past 2-3 days have been frantic!
On 12/12/12 18:00, Michał Marczyk wrote:
@Jim: That function generates factory functions which themselves use no reflection and incur no performance penalty at all. The only performance hit visible at runtime comes from the fact that generating those factory functions involves compiling code at runtime (but you should hopefully be able to arrange things so that you only need to do it once per type).
aaa ok that is good to know...I'm not sure what you mean by "re-arrange things so that you only need to do it once per type " though. I am only interested in creating pieces of a single type per 'session'. My lib for writing board games (core/gui/searching/ai) deals with one game at a time. IN other words you can't open up a single gui showing 2 games or do any tree-searching for that matter! That makes sense right?
Also, the class named by the recordname argument needs to exist when record-factory is called, so I'm not sure it can really be of much help in dealing with circular dependencies.
Well, surely it must 'exist', however it doesn't have to be :required or :imported or :used so you avoid creating circular dependencies in the first place. I can confirm this because for example, my 'games/chess' ns depends on 'lib/core' which depends on 'lib/util' (where the record-factory is) and i can create a ChessPiece record by passing the fully qualified record-name from chess.clj -> core.clj -> util.clj and get back the actual ChessPiece object. No circular dependencies. If i didn't have that, I'd have to :import ChessPiece in util.clj and in fact the end-user would need a way of injecting :imports into util.clj which I 'm not even sure it's possible. Now the end-user uses ctor directly (which he has access to as he is the one who define the pieces for the game he's writing). However it is perfectly possible to go the "long way" and pass a string to core.clj and then to util.clj and return the object back to chess.clj. I'm certainly not advocating this is a good or a nice approach but it can be done if performance is not considered critical. In fact, the discussion going on on this thread is quite enlightening... I never realised people were having so many problems with circular dependencies.
Jim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
