🚀 go-pugleaf

"Juan Carlos Rodriguez" <JUANCA@sergied.dis.ulpgc.es> writes:
	...
>following characteristics:
>1) Its keyword will be "publiconst".
>2) For the own class and its friends the attributes affected
>   acts as regular "public".
>3) For the rest, the attributes are seems as "const".
>4) The "publiconst" functions are as "public".

>Improve.
>     The new access way will eliminate the tedious work of
>write functions to protect the external access to interesting
>class attributes.

The probability of such a large change being adopted at this stage is
as close to zero as it matters, of course, making it all academic, but
I think it worth discussing why it would be a bad idea, anyway...

Providing access functions to class attributes is a particular style,
and generally _not_ a particularly good one -- in my experience, it
tends to result from under-design.  Why does everybody need read access
to those attributes -- why are the attributes in the class
_interface_?  Sure, there _are_ cases in which a property of an object
that its clients will want to query happens to be best _implemented_ as
a data member of the object's class, but how frequent is such a
_coincidence_?  Surely not frequent enough, in good OO design style, to
make it _tedious_ to provide the accessor explicitly in those special
cases!  Overabundance of accessors may indicate that the class, instead
of having been _designed_ as an abstraction of something, was built
"from the implementation up" -- i.e., underdesigned.  _Encouraging_
such underdesign, by providing special syntax to remove the tedium
connected to it, hardly seems to be a worthwhile goal...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]