On Sat, 3 Sep 2011 13:43:42 -0700 (PDT) HamsterofDeath <d.haup...@googlemail.com> wrote:
> this might seem like a stupid question, but for me, not knowing the > type of something is like being stuck in a dead end for anything non > trivial. It's not stupid, it's normal :) In functional programming, most of the time you would like to write functions that do not need to know their arguments too intimately. You would like to work on collections, maps, ... Of course at some point you will need to write functions that will look closer to their arguments. You can pass functions to generic ones and isolate that type knowledge within them. No need to spread this everywhere. > i've made a few little experiments with clojure (not much, > just testing some features) and i see how powerful clojure can be - > for small to medium sized problems with simple input and output - a*- > pathfinding, for example. > > but how would i port a complex object graph (let's say 15 different > classes with 3-7 fields each - person, contacts, orders, shipping > details) to clojure? how would i handle it? defrecord might help you a bit here. It may feel a bit "like home". defrecord fields can be referenced as map entries (:field-name ...). You can also define protocols that associated with defrecord and may ease your pain by implementing familiar functions to navigate in the hierarchy. Not sure if using a library written by someone else to handle these things is the proper thing to do right now. I feel you need to break your teeth a bit :) (It took me three months to get used to immutability :)) > the main problems i see are: > * do i have to actually remember the complete structure and field > names and the exact spelling? using statically types languages like > java or scala, the ide autocomplete features really help here. If you use obvious names that match the problem domain this should be easy to overcome. Protocols could help you here by hiding some complex navigation but please refrain implementing "getters" for all individual fields :)) > * what about renaming a field or method? Yep of course you will not have this nice refactoring feature where you type in place the new name and get the IDE to fix this everywhere for you. But on the other hand you should have at least 10 times less code compared to java and less side effects to debug. It should not be too hard to do this using a standard text search. I use Eclipse and the straight "file" search. I would never exchange Clojure for Java and the automated "Refactoring" commands. If you encapsulate frequently exposed fields in functions you should be able to reduce the footprint of the code where these things are exposed. Hence the name changes would be easy to implement. You would confine these functions in a specific name space which decrease the like hood of missing a change. > * if a function needs an instance of the root class of the complex > graph above as a parameter - how do i know this at all? am i lost > without good documentation of this function? in java, i just know what > a method needs because it has a signature. > Use the doc string when defining a fn: (defn blbl "Returns the meaningful "blblblbl..." string. It expects a single parameter, the length of the returned string" [length] ...) You can describe the expected inputs and the result, ... Do the same thing with your name space definitions, protocols. ... It's easy, fits with your programming flow and is non-obtrusive. -- Luc P. ================ The rabid Muppet -- 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
