Xref: utzoo comp.lang.c++:12835 comp.std.c++:822 comp.object:3134
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!spool.mu.edu!uunet!mnemosyne.cs.du.edu!cag
From: cag@mnemosyne.cs.du.edu (Chris Gantz)
Newsgroups: comp.lang.c++,comp.std.c++,comp.object
Subject: Re: C++ possible new construct proposal
Message-ID: <1991Apr12.182314.12855@mnemosyne.cs.du.edu>
Date: 12 Apr 91 18:23:14 GMT
References: <1991Apr11.155803.5410@mnemosyne.cs.du.edu> <fuchs.671459891@t500e0>
Reply-To: cag@mnemosyne.UUCP (Chris Gantz)
Organization: Math/CS, University of Denver
Lines: 83

In article <fuchs.671459891@t500e0> fuchs@t500e0.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
>cag@mnemosyne.cs.du.edu (Chris Gantz) writes:
>
>>        class X {
>>         type:
>>                private:
>>                     // internal data representation for type;
>>		     int no_instantiations;
>>                protected:
>>                     // protected interface for type;
>>                public:
>>		     int instantaitions() {
>>		        return instantiations;
>>		     }
>>		     void update_instantiations() {
>>			 no_instantitations++;
>>		     }
>>         object:
>>                private: 
>>                     // internal data representation for objects; 
>>                protected: 
>>                     // protected interface for objects;
>>                public: 
>>                    X() { // default constructor 
>>                          update_instantiations() 
>>			  // object appropriate internal data initialization.
>>		    } 
>>                   ~X() { } 
>>		    void f() { }
>>        };
>
>
>>	main()
>>	{
>>	    X x_obj;
>
>>	    x_obj.f(); // using x_obj through the object public interface
>>	    // below is an example of using the type X as an object...
>>	    no_current_instantiations = X.instantiations();
>>	    
>>	}
>
>Your proposed addition has been done in C++ version 2.
>It's called "static member functions":
>
>class X {
>  static int no_instantiations;
>  static void update_instantiations() { no_instantitations++; }
>public:
>  X () { update_instantiations(); }
>  static int instantiations () { return no_instantiations; }
>  void f ();
>};
>
>main () {
>  X x_obj;
>  x_obj.f ();
>  no_current_instantiations = X::instantiations ();
>    // or x_obj.instantiations ()
>}
>--
>
>Harald Fuchs <fuchs@t500e0.telematik.informatik.uni-karlsruhe.de>

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?

-Chris (cag@cs.du.edu)


-- 
Chris Gantz                             
Dept. of Math & Computer Science        Internet: cag@mnemosyne.cs.du.edu
RM 306, JGH                                       cgantz@diana.cair.du.edu
University of Denver                              cag@aragtap.den.mmc.com