|
|
|
|
|
by pozorvlak
3391 days ago
|
|
I was really trying to make a narrower point here - that there is a reasonable way to distinguish "part of the language" from "part of the (standard) library" - but I'll bite :-) attr_accessor, as it happens (http://ruby-doc.org/core-2.0.0/Module.html#method-i-attr_acc...) is implemented in C code, but one could implement it in Ruby, so I'd count it as part of the (standard) library, and creating accessors is just using a library method. In, say, Java setters and getters have to be written by hand (or autogenerated by some external system like an IDE), so they're a pattern. On the other hand, the way Ruby translates `foo.bar = 3` into a call to `foo`'s `bar=` method is not alterable by user code, so it's part of the language. MVC in Rails is an interesting case. You have to create new classes according to the pattern (either by hand or using `rails generate`), but there's also some library support in the form of Model and Controller classes you're expected to inherit from, and which handle much of the View/Controller plumbing for you. I'd say it's still a pattern, though. |
|
Yeah - I heard your point when I first read your post, but it took some more time and reading to understand it. It's a good distinction.
What I'm not getting is... So you've got a really precise and elegant line between "language" and "library", but it's not clear what the difference is between patterns and.... maybe idioms?
attr_accessor, has_many, and carrierwave's mount_uploader (to provide many examples) are all examples of a "pattern" (in the sense of a repeated thing, not a design pattern) in Ruby, but I can't determine what's then in need of "fixing" or what abstraction features could be added to remove the "pattern".