Hello C++ netters,

I don't know if this subject has been address before on the net, but I have
been thinking about a possible C++ implementation of the following Object
Oriented Programming Concept that may be useful for the development of large
systems.  The Concept is being able to utilize a "Type" as though it were an
object. This mechanism could be valuable because it would allow a logically
clean way of managing type information.  That is, information that is relevant
only to types and not logically relevant to instances of a type. Below is an
example that illustrates a simple declaration and use within the C++ framework.

        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();

 }


I believe that this language inclusion would integrate nicely with what
is already available and not add any new anomalies in the language..
Well I have on my asbestos suit on, so flame away people, but I do hope
that some people will consider the possible addition useful.

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
Denver, CO 80208                     Voice:    (303) 871-3095

Martin Marietta Corp.             Internet:    cag@airob.mmc.com
M/S XL4370                                     cag@maxai.den.mmc.com
P.O. Box 1260.                                 cag@aragtap.den.mmc.com
Denver, CO 80201-1260                Voice:    (303) 971-3347

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

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>

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

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 <fuchs@t500e0.telematik.informatik.uni-karlsruhe.de>

In article <1991Apr11.155803.5410@mnemosyne.cs.du.edu> 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();

>  }

The first thing that comes to mind is to wonder what your proposal
would do that static members can't?  The following works right now:

 class X {
 private:
  // internal data representation for type;
  static int no_instantiations;
 public:
  static int instantiations() {
   return no_instantiations;
  }
  static void increase_instantiations() {
   no_instantiations++;
  }
  static void reduce_instantiations() {
   no_instantiations--;
  }
 private:
  // internal data representation for objects;
 protected:
  // protected interface for objects;
 public:
  X() { // default constructor
   increase_instantiations();
   // object appropriate internal data initialization.
  }
  ~X() {
   reduce_instantiations();
  }
  void f() { }
 };
 int X::no_instantiations = 0;


  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...
  int no_current_instantiations = X::instantiations();

  }

So the question is: what would your proposal do that cannot already
be done just as easily?
--
    --Andrew Koenig
      ark@europa.att.com