scoped_attr_accessor 1.0.0 → 1.0.1

data/README.md

@@ -6,54 +6,6 @@ scope of code that comes afterward. You can extend a single class (and
 its subclasses) with scoped accessors, or you can extend ruby's entire
 class hierarchy.
 
-## Why Oh Why Does This Exist?!?
-
-At the time of this writing (April 2013), the ruby community in
-general is somewhat divided on the meaning of the concept of privacy
-in ruby. For some, especially those who come from Java, C++, VB, or
-some other language that enforces encapsulation with privacy, ruby's
-ability to get around privacy means that encapsulation cannot be
-enforced. Most of us (I count myself in this camp) have discarded the
-use of privacy in ruby altogether, as if it were nothing more than a
-half-hearted nod to other languages' encapsulation practices. Make
-everything public, since everything's ultimately public anyway, we
-say; using the private keyword is merely a speedbump which adds no
-security but does add hassle and headache.
-
-I am becoming more and more aware of a number of rubyists who consider
-the use of private and protected methods in ruby to be a useful way to
-communicate to the reader that the code is highly volatile, under
-question, subject to change or outright removal, etc., and that for
-these reasons the code should not be surfaced to the public API of the
-class. They ALSO consider the private keyword to be merely a
-speedbump, but one which communicates that maybe you should slow down
-a bit before trying to access these portions of code. Furthermore,
-making these methods private or protected makes them "exemplary" to
-maintainers of the code, meaning that a maintainer will understand the
-intent of the privacy, and be less likely to *accidentally* create an
-external dependency on on a method that should have been kept private.
-
-I am becoming more and more swayed by this second way of thinking, but
-I find that it falls short in one key area: accessors. It is easy to
-create a private method in ruby, but creating a private accessor
-method is actually a bit tortuous. As a result, I see programmers who
-strongly believe in using privacy to communicate undependable
-interfaces frequently making use of either instance variables or
-public accessors for their private variables. These variables are not
-dependable, at least from a "stable interface" standpoint, so both
-solutions offer an unfavorable tradeoff. While instance variables
-communicate privacy, they force the object to depend on its own
-undependable internal interface. Meanwhile, public accessors allow the
-class to isolate itself from its undependable interface, but by making
-it public the communication to the maintainer is that other classes
-can and should depend on that undependable interface.
-
-The reason programmers make this tradeoff is that there doesn't seem
-to be an easy, clean, *elegant* way to create private and protected
-accessors in ruby. My goal with this gem, then, is to create such a
-way, so that those who wish to communicate "this variable is
-undependable and it should be kept isolated for now" can do so easily.
-
 ## Installation
 
 Add this line to your application's Gemfile:
@@ -125,3 +77,51 @@ Tested to work on Ruby 1.9.3 and 2.0.
 1. Commit your changes (`git commit -am 'Add some feature'`)
 1. Push to the branch (`git push origin my-new-feature`)
 1. Create new Pull Request
+
+## Why Oh Why Does This Exist?!?
+
+At the time of this writing (April 2013), the ruby community in
+general is somewhat divided on the meaning of the concept of privacy
+in ruby. For some, especially those who come from Java, C++, VB, or
+some other language that enforces encapsulation with privacy, ruby's
+ability to get around privacy means that encapsulation cannot be
+enforced. Most of us (I count myself in this camp) have discarded the
+use of privacy in ruby altogether, as if it were nothing more than a
+half-hearted nod to other languages' encapsulation practices. Make
+everything public, since everything's ultimately public anyway, we
+say; using the private keyword is merely a speedbump which adds no
+security but does add hassle and headache.
+
+I am becoming more and more aware of a number of rubyists who consider
+the use of private and protected methods in ruby to be a useful way to
+communicate to the reader that the code is highly volatile, under
+question, subject to change or outright removal, etc., and that for
+these reasons the code should not be surfaced to the public API of the
+class. They ALSO consider the private keyword to be merely a
+speedbump, but one which communicates that maybe you should slow down
+a bit before trying to access these portions of code. Furthermore,
+making these methods private or protected makes them "exemplary" to
+maintainers of the code, meaning that a maintainer will understand the
+intent of the privacy, and be less likely to *accidentally* create an
+external dependency on on a method that should have been kept private.
+
+I am becoming more and more swayed by this second way of thinking, but
+I find that it falls short in one key area: accessors. It is easy to
+create a private method in ruby, but creating a private accessor
+method is actually a bit tortuous. As a result, I see programmers who
+strongly believe in using privacy to communicate undependable
+interfaces frequently making use of either instance variables or
+public accessors for their private variables. These variables are not
+dependable, at least from a "stable interface" standpoint, so both
+solutions offer an unfavorable tradeoff. While instance variables
+communicate privacy, they force the object to depend on its own
+undependable internal interface. Meanwhile, public accessors allow the
+class to isolate itself from its undependable interface, but by making
+it public the communication to the maintainer is that other classes
+can and should depend on that undependable interface.
+
+The reason programmers make this tradeoff is that there doesn't seem
+to be an easy, clean, *elegant* way to create private and protected
+accessors in ruby. My goal with this gem, then, is to create such a
+way, so that those who wish to communicate "this variable is
+undependable and it should be kept isolated for now" can do so easily.

data/lib/scoped_attr_accessor/version.rb

@@ -1,3 +1,3 @@
 module ScopedAttrAccessor
-  VERSION = "1.0.0"
+  VERSION = "1.0.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: scoped_attr_accessor
 version: !ruby/object:Gem::Version
-  version: 1.0.0
+  version: 1.0.1
   prerelease: 
 platform: ruby
 authors:
@@ -111,7 +111,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: 4018385502197385766
+      hash: -2597970377507506024
 required_rubygems_version: !ruby/object:Gem::Requirement
   none: false
   requirements:
@@ -120,7 +120,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: 4018385502197385766
+      hash: -2597970377507506024
 requirements: []
 rubyforge_project: 
 rubygems_version: 1.8.25