cag@mnemosyne.cs.du.edu (Chris Gantz) (04/11/91)
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. Studentfuchs@t500e0.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) (04/12/91)
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>
ark@alice.att.com (Andrew Koenig) (04/12/91)
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
cag@mnemosyne.cs.du.edu (Chris Gantz) (04/13/91)
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
fuchs@t500e0.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) (04/14/91)
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>