Reconsider terminology

[dry-rb]

Reconsider terminology

[timriley]

I'm going to make it Dry::View.

[solnic]

Does it sound too ugly Dry::View::View?

Yes this would be horrible 😆

[waiting-for-dev]

Does it sound too ugly Dry::View::View?

Yes this would be horrible

Hahaha... well, I disagree 😄

[timriley]

@jodosha @AlfonsoUceda here's a run through of our current terminology for you.

The most unusual of these, as you've noted, are "controller" and "part".

I feel "controller" is actually appropriate since its job is to coordinate multiple parts of the application to prepare the data for the template. It's not really the "view" on its own, since the "view" is the combined effect of a controller and the rendering of its templates (even though within an application development context I do tend to refer to the controller classes as "views").

As for "part", I suppose you could replace it with "presenter" or "decorator", but I feel the difference in terminology here is actually helpful, as a hint that parts operate a little differently to what we've seen branded as presenters or decorators elsewhere in the Ruby ecosystem (i.e. parts have access to almost the entirety of the view rendering environment, which is part of the key value proposition for dry-view).

The other thing I like about the term "part" is how well it fits with its neighbouring concepts: part, scope, context. They're all very strongly noun-like terms, which is appropriate, since these objects are all initialized with values as state. On the other side, we have the more verb-made-noun terms, like controller, part builder, scope builder, which are functional objects, initialized with config only, with the values passing through #call. I know this is a subtle differentiation, but I made it consciously, and I do think it helps.

Anyway, if we want to tweak any naming, now is the time. Happy to continue the discussion here or elsewhere.

[timriley]

Hi again @jodosha @AlfonsoUceda, I'd love to close this off by the end of the week. Could you please consider this and let me know if you have any thoughts? Like I explained above, I'm pretty happy with the overall naming arrangement, but if there was ever a time to contemplate any changes, it is now :)

[jodosha]

@timriley Thanks for putting this together. This glossary will be extremely useful both internally and for final devs (guides).

I agree to having part to differentiate "take the distance" from concepts like presenters and decorators, but I don't think it's the case for controller. IMO that is a view, and should be named so.

Also, having controller as term in view layer (as V of MVC), it's counter-intuitive.

[timriley]

Thanks for your feedback, @jodosha :)

After thinking it through some more, I think a rename of Controller to something else would indeed be beneficial to this project and users’ understanding of it.

Like you indicated, the most obvious renaming would be Dry::View::Controller => Dry::View, but we're taking a moment just to see if we can think of any better alternatives.

Do you have any other ideas?

[solnic]

I tried to come up with a better name, but you're right - View is the best name for this class. The only downside is that it would become a namespace too, which I don't like because by inheriting from it your class will be "polluted" by other things from View namespace. Any ideas how this could be solved, or do you think it's not really a problem?

[waiting-for-dev]

Does it sound too ugly Dry::View::View? Dry::View is the namespace, and within there you have the View.

A middle way could be Dry::View::ViewController, but I also prefer just View for the MVC influences.