Is there some kind of sample chapter?
Ruby DSL Handbook
11–20 of 30 posts
Re: Ruby DSL Handbook
#12I think it needs a foreword: "your problem likely is nowhere near needing a DSL, please don't write one just because it makes you look clever". Signed: everyone who's ever used a DSL which could have been written better as a couple of dozen functions.
I'm the author. In fact, the first bit of advice I have in the book is: Don't.
DSLs often involve metaprogramming, but they don't have to. I'm writing it to record the code practices that I have found useful in getting things right and gather advice and tips from others who have done the same. DSLs are always about communication, so my goal is to create a book that helps developers communicate the purpose of the aspects of their project through code.
Re: Ruby DSL Handbook
#13Is there some kind of sample chapter?
Not yet. But you can signup for a 5-email crash course. It's being updated almost every day now as I add more content.
Re: Ruby DSL Handbook
#14I've never been a fan of using "DSL" in the context of Ruby. Sure, you can do some metaprogramming, but you cannot create new syntax, change order of evaluation, etc., which I feel is a fundamental requirement for creating real EDSLs. One simple consequence of this is that you end up having to quote a lot of things.
This surprises me. Can you offer an example of those types of problems in some Ruby code?
Re: Ruby DSL Handbook
#15I think it needs a foreword: "your problem likely is nowhere near needing a DSL, please don't write one just because it makes you look clever". Signed: everyone who's ever used a DSL which could have been written better as a couple of dozen functions.
Almost any problem can be meaningfully and usefully solved by introduction of a DSL. It's a remarkably flexible technique. Ruby is a really bad language to write good DSLs in. Metaprogramming is an awkward replacement for better DSL facilities. Maybe this book can demonstrate better techniques?
What would those be?
Re: Ruby DSL Handbook
#16I've never been a fan of using "DSL" in the context of Ruby. Sure, you can do some metaprogramming, but you cannot create new syntax, change order of evaluation, etc., which I feel is a fundamental requirement for creating real EDSLs. One simple consequence of this is that you end up having to quote a lot of things.
This surprises me. Can you offer an example of those types of problems in some Ruby code?
Let's use 'attr_reader' as a simple example. It defines a method that returns the value of a member variable. It would be nice to refer to the variable name literally, but this is not possible:
attr_reader foo
attr_reader :foo
Re: Ruby DSL Handbook
#17I think it needs a foreword: "your problem likely is nowhere near needing a DSL, please don't write one just because it makes you look clever". Signed: everyone who's ever used a DSL which could have been written better as a couple of dozen functions.
how about: every DSL should be a thin translation layer over a clean API. Too many times I've been burned by gems that provide a DSL and there's no other way to use their functionality.
Re: Ruby DSL Handbook
#18Earlier quoted context omitted.
This surprises me. Can you offer an example of those types of problems in some Ruby code?
Let's use 'attr_reader' as a simple example. It defines a method that returns the value of a member variable. It would be nice to refer to the variable name literally, but this is not possible: attr_reader foo The 'foo' above would evaluate to the contents of the variable 'foo'. So, you have to do this: attr_reader :foo Because we cannot control how this code evaluated, we must quote 'foo'. This greatly limits what w…
That's one of the things I like about Ruby DSLs. Because the DSL is just Ruby, you can do things like:
[:foo, :bar].each do |attribute|
attr_reader attribute
end
Re: Ruby DSL Handbook
#19Earlier quoted context omitted.
This surprises me. Can you offer an example of those types of problems in some Ruby code?
Let's use 'attr_reader' as a simple example. It defines a method that returns the value of a member variable. It would be nice to refer to the variable name literally, but this is not possible: attr_reader foo The 'foo' above would evaluate to the contents of the variable 'foo'. So, you have to do this: attr_reader :foo Because we cannot control how this code evaluated, we must quote 'foo'. This greatly limits what w…
Ah. I see. That Ruby doesn't afford this can be somewhat annoying.
A counter example is using "alias". It can accept bare words, symbols, or strings.
If you really wanted to get around this you could use method_missing on the class but that can open a can of worms.
Re: Ruby DSL Handbook
#20I think it needs a foreword: "your problem likely is nowhere near needing a DSL, please don't write one just because it makes you look clever". Signed: everyone who's ever used a DSL which could have been written better as a couple of dozen functions.
how about: every DSL should be a thin translation layer over a clean API. Too many times I've been burned by gems that provide a DSL and there's no other way to use their functionality.
Yes. Too often this is done even with complex procedures inside methods. A good DSL should be syntactic sugar for making things easy or at least provide some syntactic vinegar for doing non-recommended things (while still allowing them).