Article View: comp.std.c++
Article #2235Re: Proposal for a new access specifier
From: Alex Martelli
Date: Wed, 18 Oct 1995 13:14
Date: Wed, 18 Oct 1995 13:14
50 lines
3172 bytes
3172 bytes
ebiederm@cse.unl.edu (Eric Biederman) writes: ... > >It is so close to my ideal. But I have one addition. You described "abstract > >read source interface". I would like to have also "write interface": to let > >caller write just "square.Area = 10;" instead of "square.Change_Area(10)". >But you can already do this. Not across the board, but you can do it >if you want. Just make each attribute a class of it's own. You can >then overload operator = and operator int and say all of that. ... >In article <m0t4Dmy-000glNC@axpblib> martelli@cadlab.it (Alex Martelli) writes : > (Personally, it's one of their few choices > that I _dis_like, so, I'm _quite_ happy that C++ doesn't have it:-). >But it does! C++ does not have _systematized_ support for accessors and mutators, nor systematic syntactic sugar therefor. Yes, you _can_ build such accessors and mutators explicitly (obviously), and you _can_ sugar them up (both on a case-by-case basis, or more systematically with suitable templates) -- but these possibilities descend from more generalized features of the language, they're not ad-hoc constructs for the specific purpose of enabling this programming style. I most definitely do NOT object to powerful building blocks which (though possibly at the cost of quite a bit of stylistic convention and boilerplate) can be combined to support programming styles and paradigms I may or may not care for -- if I DID so object, I guess I might hate C++ as much the average crusaders for other OO languages appear to:-). What I don't particularly care for in Sather (and Eiffel and CORBA IDL, for that matter) is systematic, ad-hoc support for member accessors and mutators -- I claim it can result in encouraging a style which often stems from "under-designed" classes, classes not ``properly'' thought of as avatars of some abstract entity... 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. ]
Technical Details
Message-ID:
<martelli.814004132@cadlab>Path:
arc1-ca.pugleaf.net!in1.uu.net!bounce-backReferences:
<199509221547.JAA10782@ncar.ucar.EDU> <MATT.95Sep24112332@Austern> <44spqj$j37@nn.fast.net> <DG6q6J.EEt@mv.mv.com> <m0t4Dmy-000glNC@axpblib> <EBIEDERM.95Oct16010202@cse.unl.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!in1.uu.net!bounce-back Date: 18 Oct 95 13:14:54 GMT Approved: fjh@cs.mu.oz.au Newsgroups: comp.std.c++ From: martelli@cadlab.cadlab.it (Alex Martelli) Subject: Re: Proposal for a new access specifier Message-ID: <martelli.814004132@cadlab> X-Newsreader: NN version 6.5.0 #11 Organization: Cad.Lab Spa, Bologna, Italia References: <199509221547.JAA10782@ncar.ucar.EDU> <MATT.95Sep24112332@Austern> <44spqj$j37@nn.fast.net> <DG6q6J.EEt@mv.mv.com> <m0t4Dmy-000glNC@axpblib> <EBIEDERM.95Oct16010202@cse.unl.edu> X-Original-Date: Wed, 18 Oct 1995 08:15:32 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBMIT9+uEDnX0m9pzZAQEc+gF/bLUjfPI2eTUe8d1mqM2z28wYy7WkWZZ+ NpeSqqCwMwTnK7LcshzFb/upBD3xD7TB =+Ern