saturnflyer

I'm on a project that isn't yet on ruby 3.2 and wanted to use the new Data class. I implemented this to allow me to move to it easily.

It does still have 1 failing test about redefining the initialize method with a block, but it works for all other cases.

The Ruby 3.2 Data class is based on C code from Struct. This is all implemented with Ruby.

Interesting. What kind of stuff does this course have?

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).

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.

This surprises me. Can you offer an example of those types of problems in some Ruby code?

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.

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.

Thanks for some fantastic feedback. I haven't read the worrydream link yet, but will check it out.

thanks! I'd love to see what you do

Code Triage is great! I hope this gets more attention and signups.

The article is about writing better code. My guess is that the PHP developers who do want to write better code would probably take the advice. Is your point that nobody should ever suggest that PHP developers write better code?

He says: "Working with others to get patches accepted and bugs closed is a crucial skill in writing good code"

This article does not tell people to patch Apache. The point, as for as I can tell, is to explore the projects you use so you can learn to write better code.

Then you say "they can't patch the most used webserver in the world like that"

What is "like that"? As far as I can tell it's "working with others". Although I've never patched Apache, I'm confident I'll need to work with others to do so.

The article gives good advice. I don't understand why you would jump to the Dunning–Kruger effect to seemingly assume that the readers are incapable of following the advice.

does that make this a bad idea?

I suspect buying the book might yield some info like that.

I'm glad to see this here. I've been a beta user and it's really helped me get a good view of how far into the future money will take me.

Thanks!

There was a signup form there originally, now it's a link to my main page about the book at http://clean-ruby.com

I actually have customers on that product. But they're unfocused and unrelated. How do you add features when the customer needs aren't clear? You don't. You just kill it.

This is why I made the point about killing my other "product". I had nowhere to go with it. Perhaps I didn't say it well enough, but my initial plan was to build something but the problem wasn't marketing, it was that nobody wanted it.

My book, however, people want. I looked for what developers need first and then built a product around that, rather than thinking of something that might be nice and try to get people to buy it (like my CMS hosting).

Thanks! I didn't anticipate this kind of traffic. I'm working on it.

Less than an hour of billing and they've got new techniques and better understanding of application architecture. It's also the answer to life the universe and everything.

This is a really good question. I actually avoided recording this because I didn't want to depress myself during the writing. I spent a LOT of time on this.

It does, however, come from real-world work. My client projects have been successful from techniques in the book. I'd need to split hairs to determine what time was spent where and in the end I just needed to write.

It's the same problem with choosing a ebook platform. No tool does you any good until you are actually using it. I'm currently writing in Apple's Pages app because it was the nearest and easiest way to just get started.

The benefit of a product is that it can become many things and the hours put into it can be easily won back with more sales.

Thanks. It's hard work, for sure, but all the knowledge and experience behind it is there. Impostor syndrome must be overcome.

good point. I'll verify the citation and update it.

Thanks for clarifying. I had most of it written before posting and had forgotten the code samples. My copy of Design Patterns is packed up for a move. I've update it to refer to C++.

Actually, people have visited, but few have stayed to read. My goal is to clarify the concept. I did plenty of research before writing this including asking Lieberman and others about it. I first wondered how everyone's notion could be wrong and doubted that my understanding was correct.

This is a term that others have attempted to clarify as well http://javalab.cs.uni-bonn.de/research/darwin/delegation.htm...

I'm planning to follow up in another post, but Gunther Kniesel coined the term "consultation" (http://javalab.cs.uni-bonn.de/research/darwin/delegation.htm...) and I've used a generic "attendant" term to refer to the other object.

Here's an excerpt from my take on the 2 characteristics of consultation (or what is typically called "delegation") in my book

---- The first is the connascence of method names between collaborating objects. Connascence refers to the point and type of coupling between objects where a change in one object requires a change in the other. Consultation occurs when the message recipient forwards a message to another object which handles the response to the same message. A calculator would receive a balance message and forward that message to an account which responds to balance. Rails’ implementation of delegate does include a caveat that the message might be prefixed before it is forwarded, but the implementation is still connascent by method name. The second aspect of consultation is that the message recipient makes no modifications to the algorithm for handling the response. ----

I wrote to Lieberman to ask his opinion and he sided with NOT introducing the "consultation" term. But his reason was not because our misguided understanding of delegation is correct, his reason was because we already have a name for this: forwarding. The quote above is from my argument about why I think it is valuable to use the term "consultation".

I never said delegation should be redefined. In fact I'm pointing out that the GoF did the redefining. In the history of Object-oriented programming "delegation" means what it was described to be. I never said that any particular implementation is "better software design". Please show me where you got these things that I supposedly said.

In programming terms, he did. I appreciate that it is an English language word and was initially what I thought it meant. But when he applied the term he meant it specifically. Otherwise, we already have a term for this: forwarding.

So why not argue about people using "delegation" when they just mean "forwarding"?

Lieberman invented this term. It did not exist prior to his work. I have confirmed this with Lieberman himself as well as Jim Coplien and David Ungar.

The Design Patterns book sought to clarify our language yet it has this error. I'm seeking to clarify our language.

I'm the author. I'm not redefining delegation. I'm pointing out that the Gang of Four, who cited Henry Lieberman who created the term, described it incorrectly. You can read the citations in the Design Patterns book and see exactly what they got wrong. Here's a link to Lieberman's work http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...

Really!? So PHP simplifies all this for you, huh?