Xref: utzoo comp.lang.c++:12845 comp.std.c++:825 comp.object:3153 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!unidui!unido!ira.uka.de!t500e0!fuchs From: fuchs@t500e0.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) Newsgroups: comp.lang.c++,comp.std.c++,comp.object Subject: Re: C++ possible new construct proposal Message-ID: Date: 13 Apr 91 17:43:03 GMT References: <1991Apr11.155803.5410@mnemosyne.cs.du.edu> <1991Apr12.182314.12855@mnemosyne.cs.du.edu> Sender: news@ira.uka.de (USENET News System) Organization: University of Karlsruhe, FRG Lines: 19 cag@mnemosyne.cs.du.edu (Chris Gantz) writes: >I agree with your above implmentation by utilizing static members. However, >my proposal is not arguing that it can't be done currently, my argument and >the reason for the proposal is that with the above implementation you are >maintaining information within an instance (ie object) that is logical infor- >mation that pertains to "types" and not "objects" of that type. Which can, >in large systems, add to the complexity of the instance (ie objects) when there >is a clear delineation between what is a logical "type abstraction" and what is >an "object abstraction". Also, isn't the object oriented paridigm trying to >make the managment of complexity and modularization of logical entities as >simple as possible? Uh? Member functions and static members exist only once, regardless how many objects you have. So I don't see any addition to complexity. Whether calling it "static" or "type" variables is just syntactic sugar. -- Harald Fuchs