Disqus - Latest Comments for sandal

Re: Practicing Ruby - Issue #23: SOLID Design Principles

Gregory Brown — Thu, 13 Nov 2014 20:46:51 -0000

This merits a longer response than something I'd like to type into a Disqus box, so please email me (gregory at practicingruby dot com) and I can give you some suggestions.

Re: Cryptic Ruby Global Variables and Their Meanings

Gregory Brown — Fri, 09 May 2014 14:24:13 -0000

Thanks, this was amazingly helpful!

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Gregory Brown — Mon, 28 Apr 2014 09:26:22 -0000

In tghese cases I've been trying to avoid modules entirely and just use an object. E.g.

SomeNamespace = Object.new
class << SomeNamespace
def some_function
end

It facilitates calling SomeNamespace.some_function but cannot be instantiated, mixed in, inherited from, etc. It feels like a hack, and I wish Ruby had a plain "namespace" construct, but it doesn't.

The only reason I might *not* use this technique is because it is unfamiliar to others. But it is actually easier to explain than extend self, which many regard as magic.

Re: Don't mix in your privates - The Pug Automatic

Gregory Brown — Thu, 13 Feb 2014 13:02:06 -0000

Hello world is a pretty terrible example, but damn it's easy to write. ;-)

Re: Don't mix in your privates - The Pug Automatic

Gregory Brown — Thu, 13 Feb 2014 12:55:06 -0000

The Greeter::Mixin idea is much more solid, I agree. Thanks for updating the post!

Re: Don't mix in your privates - The Pug Automatic

Gregory Brown — Thu, 13 Feb 2014 12:20:32 -0000

I think the problem is mostly that in the small, these distinctions don't matter that much, but in the large delegation is almost always going to be safer and more workable.

Modules offer only a minor convenience in most cases, at the potential cost of a big mess later. So I think they're a bad default choice for modeling.

There are some circumstances where "use a module" is what you want, because you actually intend to share internal implementation details. In those cases, using delegation on its own will be noticeably cumbersome, and that may be a sign that using a module is reasonable even if it has its own drawbacks.

Even then I usually try to use the module to provide just some conveniences for the user, and still mostly rely on delegation under the hood. Here's an example of a hybrid mixin from Prawn which I suggested as an alternative to subclassing its document class:

https://groups.google.com/f...

With all of this, context matters a great deal. But if you are going to go through steps to make your use of modules cleaner, it may be a sign that some alternative would be better yet.

Re: Don't mix in your privates - The Pug Automatic

Gregory Brown — Thu, 13 Feb 2014 11:34:37 -0000

The name collision with constants is easier to come by than you might expect:

https://gist.github.com/san...

Also, a better solution is to simply not use modules at all. It avoids the risk of any collisions:

https://gist.github.com/san...

For a much longer story about this, see:
notes.practicingruby.com/20...

Re: Some thoughts on intellectual honesty

Gregory Brown — Thu, 10 Jan 2013 09:01:23 -0000

If you have an idea for a talk that you fear won't get traction because it doesn't speak in absolutes, but the technical ideas are good and worthwhile, please do consider contributing an article to Practicing Ruby. I welcome that sort of thing :-)

You can follow up with me at gregory@practicingruby.com

Re: Do-it-yourself Night School

Gregory Brown — Sun, 23 Dec 2012 12:00:30 -0000

I think that would have definitely helped me keep up with this goal too! I think this is also the kind of thing that benefits from local interaction. Maybe it's time to start "Learn anything" users groups :-)

Re: The DCI paradigm is a scam

Gregory Brown — Sat, 22 Dec 2012 11:48:01 -0000

Couldn't agree more. My concern about DCI so far has not so much been whether it should be used or not, but more that we've been lacking specific examples to discuss tradeoffs within.

Comparing costs and benefits in the abstract is too slippery. I'm glad you've put forth some specific code for us to discuss, I think that'll make a big difference.

Re: The DCI paradigm is a scam

Gregory Brown — Sat, 22 Dec 2012 09:39:47 -0000

This is exactly what I was hoping to see! I'm going to need to take some time to decide what I think of it, and to perhaps play around with the code a bit, but thanks a lot for writing up a very detailed and thoughtful post on this.

Re: The DCI paradigm is a scam

Gregory Brown — Fri, 21 Dec 2012 06:48:33 -0000

It's definitely a nice example, but at that scale, DCI still looks quite heavyweight and high ceremony. I want to see an example in which the application complexity is brought down by DCI rather than increased.

Re: The DCI paradigm is a scam

Gregory Brown — Thu, 20 Dec 2012 14:13:29 -0000

That tweet is pretty much the feeling I have about what I saw in Martin's architecture talk though :-)

Re: The DCI paradigm is a scam

Gregory Brown — Thu, 20 Dec 2012 12:21:08 -0000

Thanks for sharing that. I haven't watched the video yet, but I did flip through the slides. Lots of the stuff I see in there I'm quick to think "hmm... that looks interesting" or "that might work!", but then when I get to the IterationWorkflowInteractor example on slide 34, that's where I start to make the o_O face.

To get over my confusion, I think what I need to do is build something and then ask someone experienced with DCI to refactor it into something they think would be a good design, and then explain to me why they think that.

Re: The DCI paradigm is a scam

Gregory Brown — Wed, 19 Dec 2012 23:49:25 -0000

#1 Thanks for reminding me of that book, I forgot about it and now I'm putting it back on my wishlist. :-)

As for Uncle Bob's talk, someone asks about whether he's built an application using these concepts, and he says "I have, but I can't share it". The emphasis on this point is I want to see the code, preferably extracted from a real project!

#2 You're absolutely right: some aspects of design can be observed in the small, but most apps that require any architecture at all are reasonably complex. The problem here is that unlike many other established architectural patterns, DCI seems to be at the stage now where it is theoretical and constructed rather than practical and extracted. It'd move the discussion forward hugely to see a proper case study. I understand this may take time and effort that has not yet been invested, but I think it's a prerequisite for getting excited and enthusiastic about the pattern rather than simply being hopeful and curious (which is the stage I'm at right now).

Thanks for your comment, and thanks a ton for putting forward the DCI app example, even if it's a bit too small to be fully convincing. You're doing it right, and I hope others will follow in your footsteps.

I'd also appreciate your thoughts on this alternative proposal, if and when you have the time to share them: https://gist.github.com/434...

Re: The DCI paradigm is a scam

Gregory Brown — Wed, 19 Dec 2012 11:48:23 -0000

I'm sorry that you've struggled with the concept.

This is a bad way to start a conversation. And the entire rest of your comment just ignores the three specific pieces of evidence I've asked for. Instead, you've gone back into rhetoric-mode, which is exactly what I'm trying to steer the conversation away from.

Can I get a refund on your book? Even if there is good content in it, I don't want to support you, because I feel you are overselling an unproven paradigm to the point of being misleading about it.

Re: DCI and the Open/Closed Principle

Gregory Brown — Tue, 18 Dec 2012 15:48:51 -0000

Since you came up with the same argument that I did, I'm going to try to play the other side of it just to see what we can learn from it.

1. The traditional approach to OCP has been to use class inheritance (Customer < User).
2. Using the instance-level mixin form of DCI provides similar functionality, but the impact of inheritance is more isolated, and non-hierarchical. As a result, it should be easier to maintain.

This is basically a valid argument, if we assume that #1 is our starting point, and #2 is an improvement on #1. What I think it leaves out however is that many of these principles were developed for use within statically typed, class-centric programming languages.

Let's assume that is the case. If so, then the argument of composition vs. inheritance is more cumbersome. You'd need to define customer like public Customer(User user) { ... }, and so you'd be explicitly coupling the interface level. Now, maybe User is an interface or a generic, but it's still a concrete concept you need to define, and so it has some costs associated with it that make the inheritance approach feel a bit more palatable.

But when we use a dynamic language, like Ruby, we don't need to explicitly declare that interface. This has its own sets of advantages and disadvantages, but because polymorphism and duck typing are baked in, we don't have to concern ourselves with these formalities: if we know what fields on a user we must manipulate, we don't need to care about how it is implemented. In fact, fundamental object oriented principles such as encapsulation tell us we SHOULDN'T know, and if DCI is to cut against that grain, we should come up with a good reason *why*.

In this environment, we don't have the same arguments that would cause us to pick inheritance by default in Java or C++. That does NOT mean we have proven composition to be a better way, but it does mean that we can't simply assume the default and try to optimize from there.

My gut tells me that we (as a community) aren't well versed enough in composition-based modeling, and so we fail to see its benefits when we try to use inheritance-based-thinking with composed objects, rather than composition-based-thinking. I do think this distinction is relevant to DCI: we need to figure out whether the implementation can be decoupled from the idea or not. If so, then we should invest time in finding out the best way to implement it. If not, we need to know what the cost of implementation is in relation to the proposed benefits. If we don't consider those questions, it feels as if we're cargo culting an idea rather than developing it for real use.

Re: DCI and the Open/Closed Principle

Gregory Brown — Tue, 18 Dec 2012 15:07:59 -0000

I forgot to answer your other question:

If I rewrote this article using decorators, would that validate it?

Actually, yes! It would validate the idea that role-based programming is perfectly cohesive with composition-based programming that respects the Open/Closed principle in a very strict way. It'd require a few characters of change in your code samples, and would drop the number of concepts required to *truly* understand the code down by several hundred hours of dedicated study.

Re: DCI and the Open/Closed Principle

Gregory Brown — Tue, 18 Dec 2012 15:03:53 -0000

It's not for the sake of student digestibility: this is not a question of easy to learn vs. not, it's a question of few vs. more concepts. More concepts means more edge cases, more sources of potential failure, and more things to learn. More concepts *might* mean more opportunities, but it does not mean that by default. What specifically are the added benefits of using inheritance, beyond inertia and legacy?

As for the idea of modeling close to the real world, again, I'd ask: what is the significance of doing so at the *implementation* level, and not the *behavioral* level? This to me is a strawman: a mixed in module is no more "real world" than a class called Customer. When we walk into a store, we don't get functions that allow us to shop coherently shotgun blasted into our brain, so the "real world" analogy sounds a lot more like rhetoric than substance.

It's a shame to me that DCI seems to be eating its own tail by focusing on implementation details rather than the very real and very useful idea of role-based programming at the behavioral level. I'd love to see an argument that wasn't dependent on DCI's "philosophy" and instead was a falsifiable technical statement. Until we actually put forth experiments that have real answers to them, this is a whole lot a style for little substance.

Re: DCI and the Open/Closed Principle

Gregory Brown — Tue, 18 Dec 2012 12:21:57 -0000

Why is being "indistinguishable" at the implementation level (as opposed to the contractual level) an advantage?

Also, there is a huge difference between something being canonical because it is widely used, and it being canonical because it is widely proven as a good idea. I'd suggest focusing on the cost side of the equation rather than the benefits, and to do that, I have a little thought experiment to try out:

Think through in your head how you would explain from first principles how the code you have shown here works, to someone who does not have an understanding of the Ruby object model. Then, make the small adjustment of using Customer.new(user) instead of user.extend(Customer). Now run the experiment once again from first principles and explain how it works.

If you find that the former is no harder to explain than the latter, than sure, within this narrow context, then maybe that'd explain why you feel that there is little benefit to using composition. But I've tried this exercise many times myself, and I've always found teaching the nuances and limitations of inheritance to be several orders of magnitude more complex than teaching how simple objects communicate through message passing.

Just because we spent years internalizing the details of inheritance doesn't mean that we should encourage future generations to do the same. We need a stronger reason than that to continue to advocate its use. I am worried that DCI is doing more harm than good because of how it papers over these issues.

I have a pair of articles that are based on primary research materials that might be worth reading to really gain an understanding of the *costs* of inheritance, and the fundamental misunderstanding of "behavioral types" vs. "abstract data types":

Criteria for Disciplined Inheritance: Part 1, Part 2

You could use my content as a starting point, but I'd really recommend going back to the papers by Sakkinen and Liskov/Wing that they reference. If you come out the other end still holding the views you do about this topic, I will be *very* interested to hear your thoughts.

Re: DCI and the Open/Closed Principle

Gregory Brown — Tue, 18 Dec 2012 11:34:24 -0000

To me, the value of the Open/Closed principle is the ability to *ensure* that modification remains closed. So I view the use of a subclass as sort of a "poor man's OCP", and DCI style extension of an instance as kind of a "working man's OCP", but certainly not a king.

DCI does allow us to *isolate* our code that breaks encapsulation: It is closed in the sense that it does not modify the class definition, but it is not closed at all at the per-object level: you can still have accidental name collisions on both methods and variables, and late binding means that these problems can happen before OR after your code was mixed in. Granted, if you keep your base object data-centric and only mix collaborating roles into them, you will reduce the likelihood of this happening, but that's entirely by convention, not enforced at the object model level.

Real OCP in my mind is simple object composition, i.e. Customer.new(user).purchase_book. When you model things this way, Customer has its own namespace for variables and methods that is independent of the User object, and so it truly treats the User object as if it were closed for modification. What are the significant downsides of this approach that DCI solves? I've had a hard time coming up with them myself.

TL; DR; The real "king" of the Open/Closed principle is simple object composition, and not *anything* that uses inheritance-based modeling, even instance-level mixins.

Re: Towards a Common Ruby definition

Gregory Brown — Thu, 13 Dec 2012 17:02:13 -0000

Ella, yeah, just a list of the scores would go far. But I wonder whether MRI should be the default implementation of RubySpec by which that score is generated, or whether there should be an official label for an agreed upon intersection. Hence, "Common Ruby".

As for bureaucracy, its an interesting question as to how much is necessary. We all want the freedom to experiment and we don't want to see stagnation, but to even be discussing this issue, we are by definition very embedded in Ruby. Brian seems to want to consider a much broader cross-section of the Ruby ecosystem, and for them, some degree of process and standardization would be ultimately beneficial. That's why I think that a standardization effort could be treated as a project of its own, to live or die under its own merit.

Re: Practicing Ruby is not for everyone

Gregory Brown — Tue, 20 Nov 2012 16:13:49 -0000

Hi Roberto,

Thanks for the feedback. I like the name "Practicing Ruby", because means practice in the sense of "Theory vs. Practice", and in the sense of "actively practicing your craft". But its true that it can also be interpreted as "doing exercises" or "honing a particular skill" and that has a very different meaning!

Re: Matz is not a threading guy Matz não é um cara de threading

Gregory Brown — Thu, 08 Nov 2012 09:00:38 -0000

Thanks for this writeup Jesse. It's nice to see a summary of this contentious issue that isn't steeped in FUD. ;-)

Re: Traitor - an Implementation of Traits for Ruby 2.0

Gregory Brown — Wed, 07 Nov 2012 18:05:47 -0000

Neat idea!

When I run your example, the TraitError is not actually raised. Perhaps this is due to the default implementation of Object#== existing already? If I explicitly undef :== in Rectangle, it does work as expected.

I like that traits are non-hierarchical in nature, and that they force explicit conflict resolution. This makes them a nice alternative to modules, and I think the trait_send method is a neat idea. It'd be nice if there were a way for trait_send to implicitly infer the method to be called, but I suppose something like trait_send(Reciever, __method__, *args) would be a reasonable way to write maintainable calls that don't need to be updated if the method name changes.

The main concern I have with this approach is that it still leads to complicated namespace pollution within an object, and can lead to accidental clashes with method names and instance variables. I suppose these problems exist more in huge objects like ActiveRecord, but it's the thing that has always bugged me the most about modules, and it's still present here. I wrote at length about this topic over on Practicing Ruby, and I'd be interested to here what you think of it:

Criteria for Disciplined Inheritance, Part 1:
https://practicingruby.com/...

Criteria for Disciplined Inheritance, Part 2:
https://practicingruby.com/...

The underlying papers that it is based on are also awesome, but much more abstract and not Ruby-specific at all:

M. Sakkinen, Disciplined Inheritence:
http://www.ifs.uni-linz.ac....

Liskov/Wing, A Behavioral Notion of Subtyping:
http://citeseerx.ist.psu.ed...

All that having been said, it's neat to see a more restrained alternative to modules, even if it is experimental. A purely composition-based model may prove to be too awkward, but something like this might be a nice compromise.