3 ms·

I really, really like this idea. It's difficult enough to employ Ruby's metaprogramming constructs without making a mess, so the idea of instantly decomposing i

I really, really like this idea. It's difficult enough to employ Ruby's metaprogramming constructs without making a mess, so the idea of instantly decomposing into nested lists is really appealing. I realize the library is only, like, three days old, but questions/feedback: - Do the DSL methods get turned into into proper Ruby methods eventually? I'd hate to see this whole thing built on the back of method_missing. - Picking apart nested arrays can lead to its own kind of spaghetti code. When people build DSLs, I recommend they immediately turn their high-level method calls into nicely testable objects. Can we see an example of that here? - The author specifically calls out libraries like ActiveRecord, which would suggest that the primary use case for this library is for integration as a DSL layer into your own libraries, but he doesn't provide any examples of that usage--just Lispy.new. I'd like a way to extend Lispy into my own class or module and get that same functionality.

ryan-allen 16y ago
G'day, Thanks for the feedback! I was hoping to do a little more work on it before it being posted to somewhere like HN, but oh well! A lot of the work I've done with this kind of Ruby, it often only is run once, so I tend to use method_missing. The reason why you'd want it converted to methods is for performance, right? I agree with your testing comments, there's a lot left out so far, specifically a guide on how you might use such a library, I'm working on that. And yes, you're right about AR being not the best example, it's use is for what you've described. Integration with your own code would be an ideal use. Implementing it as a module would be trivial.
- pi18n 16y ago
  Is there a specific reason you chose to do arrays of arrays instead of hashes for subelements? I'd want the lists to come out as (maybe using a pluralizer or maybe not) :items => [{:priority => :normal, :desc => '...'}, ...] Then you could do more intuitive things like todo_list.items.sort{|a,b| a[:priority] <=> b[:priority] } which is somewhat stupid for symbols but not for numbers.
  - ryan-allen 16y ago
    No, no reason why I chose arrays, it's just a first cut. I was thinking of converting the representation for objects as the meaning of the three possible elements isn't explicit at the moment.
    - alttab 16y ago
      One thing to keep in mind is different Ruby implementations, versions, and platforms run differently. An array is currently the safest way to maintain order when it matters. If order didn't matter, than a hash would be fine, but iterating over the data could cause unwanted behavior if order is important and hash keys are served to an iterator in a different order than was laid out by the DSL code.
- bguthrie 16y ago
  Performance and improved introspection. Once they're first-class they get included in that class's list of methods, which is helpful sometimes. Mostly I just like to avoid m_m when I can. AR is actually an okay example - it's as good an illustration as any of a place that employs these kinds of techniques, and the source of a lot of complexity in Rails.

ryan-allen 16y ago

G'day, Thanks for the feedback! I was hoping to do a little more work on it before it being posted to somewhere like HN, but oh well! A lot of the work I've done with this kind of Ruby, it often only is run once, so I tend to use method_missing. The reason why you'd want it converted to methods is for performance, right? I agree with your testing comments, there's a lot left out so far, specifically a guide on how you might use such a library, I'm working on that. And yes, you're right about AR being not the best example, it's use is for what you've described. Integration with your own code would be an ideal use. Implementing it as a module would be trivial.

pi18n 16y ago
Is there a specific reason you chose to do arrays of arrays instead of hashes for subelements? I'd want the lists to come out as (maybe using a pluralizer or maybe not) :items => [{:priority => :normal, :desc => '...'}, ...] Then you could do more intuitive things like todo_list.items.sort{|a,b| a[:priority] <=> b[:priority] } which is somewhat stupid for symbols but not for numbers.
- ryan-allen 16y ago
  No, no reason why I chose arrays, it's just a first cut. I was thinking of converting the representation for objects as the meaning of the three possible elements isn't explicit at the moment.
  - alttab 16y ago
    One thing to keep in mind is different Ruby implementations, versions, and platforms run differently. An array is currently the safest way to maintain order when it matters. If order didn't matter, than a hash would be fine, but iterating over the data could cause unwanted behavior if order is important and hash keys are served to an iterator in a different order than was laid out by the DSL code.
bguthrie 16y ago
Performance and improved introspection. Once they're first-class they get included in that class's list of methods, which is helpful sometimes. Mostly I just like to avoid m_m when I can. AR is actually an okay example - it's as good an illustration as any of a place that employs these kinds of techniques, and the source of a lot of complexity in Rails.