Hello! I am interested in knowing more about the Object Behavior system presented by Chris Granger at Conj 2012. I find it really clean and the idea of having objects combined with the fact that "the entire hierarchy is a nested data structure that is easy to reason about and modify at runtime without the use of a fancy debugger" seems really interesting.
Where can we learn how to program like that? Who's doing this too? Where are some other code example (than Chris work)? Thanks ! >From https://news.ycombinator.com/item?id=5116234 seanmcdirmid <https://news.ycombinator.com/user?id=seanmcdirmid> 146 days ago | link <https://news.ycombinator.com/item?id=5118776> I don't really get it. From the blog post, Granger is describing a very imperative object system, but you seem to be claiming that it is somehow a value-oriented functional system. What am I missing? ----- <https://news.ycombinator.com/vote?for=5128824&dir=up&whence=%69%74%65%6d%3f%69%64%3d%35%31%31%36%32%33%34> krosaen <https://news.ycombinator.com/user?id=krosaen> 143 days ago | link<https://news.ycombinator.com/item?id=5128824> That's a good question - there are still objects, or groupings of data, and even tags that identify which behaviors or functions apply to them in various contexts. What strikes me as different is the entire hierarchy is a nested data structure that is easy to reason about and modify at runtime without the use of a fancy debugger. The use of 'encapsulation' that hid the underlying data in each grouping and also bind functions / methods directly to each object in this case would only make it harder to work with. Why? Because to view, construct, augment at runtime or serialize the hierarchy would require constructors, serializers, deserializers etc, instead of having something that is just a data structure, ready to be viewed, put on a queue, sent over the wire etc. The idea of 'behaviors' also provides flexibility in what functions can act on any grouping of data - the key value pairs needn't be associated with a 'class' which dictates what the associated functions will be adds more flexibility. As the author hints, there are other ways of achieving this agility - dynamic mixins. Finally, while having a well defined protocol (or API or endpoint or whatever you want to call it) is valuable and helps organize code, I think taking this idea to the extreme and saying that every single object or piece of data you pass around as arguments or return values from these end points needs to be expressed as an abstract protocol itself is where you really start to lose. An expected format of the data structures of the arguments and return values can and should be part of an API, but needing to wrap them in objects doesn't really help - and that's where this trend I speak of begins to seem like progress to me. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
