tag:blogger.com,1999:blog-9944221.post5813364654946697669..comments2023-11-03T06:15:55.087-05:00Comments on Meme Agora: Ruby Matters: Contracts vs. PromisesNeal Fordhttp://www.blogger.com/profile/12839796402858974817noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-9944221.post-22047262955020757842007-10-26T14:18:00.000-05:002007-10-26T14:18:00.000-05:00Sorry for the late response on this one. I'm the ...Sorry for the late response on this one. I'm the author of Handshake (and a fellow TWer) and I just wanted to drop in to mention that straight-up pre- and post-conditions don't really appeal to me either, and they aren't at the heart of what I was going for with this framework.<BR/><BR/>The beauty of it (and of Ruby) is that you can develop flexible, domain-specific predicates, reusable and concisely expressed. It can be as simple as a check for some application-specific condition on a string (for example, "must begin with http://"), and it's useful because (a) you're not cluttering up your method bodies with this kind of code, and (b) you've assigned a domain-specific name to an object with these constraints. Check out the 'contract' method.<BR/><BR/>The framework isn't particularly useful for Rails projects, but might be useful if you were building something like Rails. I've been in situations in which having it around was handy and situations in which it's gotten in my way, so I suppose I'm myself somewhat undecided on its utility. <BR/><BR/>For more information on what I was going for, check out PLT Scheme's contract system: http://people.cs.uchicago.edu/~robby/plt-contracts-guide/Brian Guthriehttps://www.blogger.com/profile/03303316202034594348noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-20249185922335183942007-10-16T14:19:00.000-05:002007-10-16T14:19:00.000-05:00I agree. Here's how I tried to persuade Java devel...I agree. Here's how I tried to persuade Java developers just yesterday: <BR/><BR/>Draw the classic Observer pattern in UML on a whiteboard. This is something that appears over and over in our design documents. With Ruby (or Groovy, for us) you get to erase one of the arrows and one of the boxes. Add closures/blocks instead of a method callback and the design is even simpler (one less arrow). <BR/><BR/>The point is that the resulting diagram is so simple that you never would put it in a design document. Your design process becomes oriented towards the function of what you're doing rather than the static structure (class diagrams). <BR/><BR/>Can we please put an end to pages of class diagrams in design documents and start thinking about the important stuff!Hamlet D'Arcyhttps://www.blogger.com/profile/04008870357169725586noreply@blogger.com