Re: Review: Base from Member

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-08-07 11:54:13

on 8/7/01 12:48 AM, Douglas Gregor at gregod_at_[hidden] wrote:

> I reviewed the documentation and code, but did not test it.
> 
> I have no comments on the code itself that haven't already been covered,
> except to revisit the naming of the "ron_" member variable. This led me to
> the question "what is a good name for this variable?" Any choice has to be
> generic enough to name any possible member variable, but because of this
> genericity it is impossible for the name to communicate any meaning to the
> user. So how does one write readable code using this idiom? Accessor/mutator
> methods can be used for clarity, but this desugaring seems to overshadow the
> benefits of using the library vs. manually coding the idiom. Using the
> library saves a small amount of typing up front (the creation of a class
> containing a single member), but it requires more typing overall to preserve
> the readability of code using this member.

In later versions, I renamed the member variable "member."

These classes are not meant to be seen by regular end users.  They are meant
for middle-ware developers.  These classes should be added with private
inheritance.  No one but the developer that specified these templates is
supposed to see them.  Since there is only one viewer, the constructors and
member variables are protected for simpler access and to discourage end-user
access.  If a client class only uses one of these templates, then the
developer can refer to his/her only base-to-member with an unqualified
"member."  More typing is necessary only if several base-to-member classes
are used in the client class's inheritance graph.

> Without the ability for a user to specify the name of the data member (which
> would require either macro tricks or a core language change), I think that
> this particular idiom does not lend itself well to being translated into a
> reusable, generic library.

I use it quite a bit in the "more_io.zip" package in the vault.  Since it's
not dependent on I/O, I put it up for separate review.

I don't think a typical developer is going to need alternate names, or need
more than one base-from-member class.  If you need to use the idiom over
many end-classes (like more_io), a template is a lot better than writing
similar code many times.  I got the idea for these class templates after
seeing Dietmar Khuel doing a bunch of manual base-from-member code for his
I/O examples.

> Overall, my view is that this library should not be accepted into Boost.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com