[mlpack-svn] [MLPACK] #118: Use consistent accessors and mutators

MLPACK Trac trac at coffeetalk-1.cc.gatech.edu
Sat Nov 26 17:09:48 EST 2011


#118: Use consistent accessors and mutators
------------------------------------------+---------------------------------
  Reporter:  rcurtin                      |        Owner:            
      Type:  wishlist                     |       Status:  new       
  Priority:  major                        |    Milestone:  MLPACK 1.0
 Component:  MLPACK                       |   Resolution:            
  Keywords:  mlpack getter setter public  |     Blocking:  120       
Blocked By:                               |  
------------------------------------------+---------------------------------

Comment (by rcurtin):

 So the scheme we have come up with has some problems.  Take this example:

 {{{
 class SomeClass
 {
  private:
   arma::mat matrix;

  public:
   SomeClass() : matrix(someDefault) { }

   const arma::mat& Matrix() const { return matrix; }
   void Matrix(const arma::mat& matrix) { this->matrix = matrix; }
 };
 }}}

 Now suppose we want to do something like double that matrix.  How do we
 have to do it?

 {{{
 int main()
 {
   SomeClass x;

   arma::mat matrix = x.Matrix(); // Incurs copy constructor.
   x.Matrix(matrix * 2); // Incurs copy constructor again.
 }
 }}}

 There's no way around that, so clearly we need to modify our rules.  If we
 now use this interface:

 {{{
 const arma::mat& Matrix() const { return matrix; }
 arma::mat& Matrix() { return matrix; }
 }}}

 then we eliminate the copies:

 {{{
   x.Matrix() *= 2;
 }}}

 but now we are unable to perform data validation.

 In my eyes we simply can't allow all those extra copies and additionally
 the ugly, roundabout syntax required when we use the `void Matrix()` style
 mutator.  So unfortunately I think we have to revisit this decision.

 Do we (hopefully I'm about to list all possible options):

  * Ignore the problem, calling data validation more important than
 unnecessary copies?  (I hope not)
  * Convert all our mutators to `type& Mutator() { return mutator; }` for
 consistency's sake, abandoning data validation?
  * Make un-validated members accessible with `type& Mutator()` calls,
 while using `void Mutator(const type&)` calls for members where validation
 is necessary?  This breaks consistency, sort of.
  * Make un-validated members public members, since `const type& Mutator()
 const` and `type& Mutator()` calls are effectively no different than
 public members?
  * Abandon MLPACK and find jobs at Mickey D's?

-- 
Ticket URL: <http://trac.research.cc.gatech.edu/fastlab/ticket/118#comment:11>
MLPACK <www.fast-lab.org>
MLPACK is an intuitive, fast, and scalable C++ machine learning library developed by the FASTLAB at Georgia Tech under Dr. Alex Gray.


More information about the mlpack-svn mailing list