In Ruby on Rails, why doesn't Devise or Restful Authentication create a namespace for better encapsulation?_问答_开发者

It seems that Restful Authentication and Devise both use

current_user
user_signed_in?    (or logged_in?)
self.current_user = ...   (for Restful Authentication)

as the "interface" to the gem. I wonder why no module or class is used to give it a namespace, such as:

Auth.current_user
Auth.set_current_user

Devise.current_user

In fact, I was a bit horrified at first to find Restful Authentication "mix in" everything, and the docs doesn't even mention an "Interface" -- isn't interface one of the most important thing in object oriented programming, that everything is encapsulated and that the interface is all the user needs to care about? Sometimes, I don't see any docs for interface, such as for Facebooker or Facebooker2, and if requesting a brief description of the API, the response can be "read the code". There can be 5 gems (1 gem and 4 gems it depends on) and at least 40 files, my friend. Does this totally violate the founding principles of object oriented progra开发者_如何学Cmming?

Back to the original question, can't Restful Authentication and Devise use a namespace and define the interface better? If it mix in all the names, (including instance variable names), won't that contaminate the Controller class? (a lot of work is done in the various controller classes, so contaminating the namespace there is almost as bad as contaminating the global namespace).

That is one of those things where there isn't a correct answer. When you mix in devise, it adds about 4 methods to actioncontroller, those methods are documented, and you should read the documentation before using any library. Basically, that is the "interface" to the gem. Everything is still encapsulated in the module, the only difference is that ActiveRecord isn't buying in to anything, the Devise library is the one doing the integration. Also, the people who are maintaining devise need to write less, and less complected code to do the integration, and you as the user don't need to write as much code to use it.

Now, in theory this is a ZOMG THE SKY IS FALLING!! type of situation. In reality, it is very rare that things crush other things, so long as they are done properly (i.e. encapsulate everything in a mixin, override the method, remember to call super). Even when you do run into these types of issues, (after the first time) it is usually really easy to figure out what is going on. It is basically a different form of inheritance, which is one of the foundational concepts of OOP.

Doing things this way also allows libraries to add features to other libraries, or even the core language. This allows for elegant solutions to really tough, situational problems. It also means that the state of the language moves forward MUCH faster then if you have to wait for any new feature to get pushed out before you can use it, and allows for cross version coding to be quite elegant through polyfills. I think it is one of the best features in any language that implements it, and find working in more restrictive languages to be a real pain because of it, you feel like you have a little police man on your shoulder telling you that you aren't smart enough to use powerful language features to solve your problems.

Now, if you say "OOP is a mess and we shouldn't have the nasty type of coupling introduced by inheritance in the first place" I would totally agree with you. But that is a different discussion :)

what do you mean by founding principles of object oriented programming? like using 2 conflicting gems in your project?

answering your question - there is no point in asking user to type more code than necessary, these 2 gems are essentially doing the same thing, just differently so real question is - why would you want to use them both?

general idea with ruby being open to monkey patching and changing classes at runtime is - developers are not stupid and will not want to do stuff that breaks their project.