www.digitalmars.com         C & C++   DMDScript  

D - Common base class is evil!

reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Why have a common base class 'object'? There is nothing common in 'date' and
'point'.

Guess most of SI v/s MI discussion stems as the language has this common
base class built in.
Sep 11 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
Rajiv Bhagwat wrote:

 Why have a common base class 'object'? There is nothing common in 'date' and
 'point'.
That's true. And D allows you to define 'date' and 'point' as structs, in which case they have no common base class. However, when you decide to implement them as classes, they are no longer 'date' and 'point' but 'class modeling date' and 'class modeling point'. In this realm, they have a number of purely structural things in common. Also, it's very nice to have an implicit way to differentiate between classes and more basic data types. A pointer to Object (or whatever the D base class is) is inherently a pointer to a reference counted class on the heap; a pointer to void might be a pointer to anything at all, including things on the stack.
Sep 12 2001
next sibling parent "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Reference counted objects? That is a possibility. For lightweight classes
like Date and Point, are we not expecting the language to look after
managing classes which do no resource allocation?

What are the implications of converting structures to classes mid-project?

Zillions of tiny objects as in the Flyweight pattern? (carrying tiny data:
such as an int or a char)

-- Rajiv


Russ Lewis <russ deming-os.org> wrote in message
news:3B9F8512.7035E7D9 deming-os.org...
 Rajiv Bhagwat wrote:

 Why have a common base class 'object'? There is nothing common in 'date'
and
 'point'.
That's true. And D allows you to define 'date' and 'point' as structs, in
which
 case they have no common base class.  However, when you decide to
implement them
 as classes, they are no longer 'date' and 'point' but 'class modeling
date' and
 'class modeling point'.  In this realm, they have a number of purely
structural
 things in common.

 Also, it's very nice to have an implicit way to differentiate between
classes
 and more basic data types.  A pointer to Object (or whatever the D base
class
 is) is inherently a pointer to a reference counted class on the heap; a
pointer
 to void might be a pointer to anything at all, including things on the
stack.

Sep 12 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
I think it's an old asked question, now what the difference between a 
struct and a public-only class? Do we need structs after all?
Sep 14 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Axel Kittenberger wrote:

 I think it's an old asked question, now what the difference between a
 struct and a public-only class? Do we need structs after all?
In C++, there wasn't any difference - in fact, you could declare private members of a struct. I think that Walter has done a Good Thing by separating the two in D. Key differences (as I understand them): * No member functions of any kind in structs (and therefore no vtable) * All members public in structs * Structs can be created on the stack; all class objects are created on the heap * Specified alignment possible in structs, not in classes I like this because it makes a separation between a hardware-like type (struct) which is simply a mapping of a conglomeration of types over a certain range of memory and a OOP-like type (class) which is a high-level programming abstraction designed to facilitate good and easy programming. This allows the program to have low-overhead access to hardware (a key feature of C) or to subroutines from other languages while still allowing high-level OO design.
Sep 14 2001
next sibling parent Axel Kittenberger <axel dtone.org> writes:
 I like this because it makes a separation between a hardware-like type
 (struct) which is simply a mapping of a conglomeration of types over a
 certain range of memory and a OOP-like type (class) which is a high-level
 programming abstraction designed to facilitate good and easy programming.
Well especially on hardware types for a certain range of memory, it would be often very nice to provide a set of functions just related to this.
Sep 14 2001
prev sibling next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Russ Lewis wrote:
 I think that Walter has done a Good Thing by separating the two in D.
I agree, but --
 Key differences (as I understand them):
 * No member functions of any kind in structs (and therefore no vtable)
For pendantry, I'll just point out that member functions in themselves don't require a C++ class to have a vtable -- only virtual functions.
 This allows the program to have low-overhead access to hardware (a key
 feature of C) [...]
And of C++, because of the above. You can even get OO encapsulation around a struct/class which represents memory-mapped hardware! -RB
Sep 14 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Russell Bornschlegel wrote:

 Key differences (as I understand them):
 * No member functions of any kind in structs (and therefore no vtable)
For pendantry, I'll just point out that member functions in themselves don't require a C++ class to have a vtable -- only virtual functions.
True. However, Walter has made the design decision that all member functions in D are virtual. That doesn't necessarily mean you'll need a vtable (if you never override functions for your 'struct', or you never call those functions by pointer), but it makes it more likely. IMHO, this illustrates the double-minded approach of C++; it can never make up its mind whether its an OOP language or a low-level language, so it tries to do both in one language element. I like the way that D does both - but separates the two into very distinct language elements.
 This allows the program to have low-overhead access to hardware (a key
 feature of C) [...]
And of C++, because of the above. You can even get OO encapsulation around a struct/class which represents memory-mapped hardware!
True. :) Ofc, the same can be done in D by declaring a member struct inside a class; the class provides the programming interface, while the encapsulated struct provides a memory interface. -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Sep 16 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 True. :) Ofc, the same can be done in D by declaring a member struct
 inside a class; the class provides the programming interface, while the
 encapsulated struct provides a memory interface.
Yes, thats always possible. But it's then a wrong IS-A, HAS-A relationship. Taken with this aproach in example you don't even need inheritance. You can always use "fathers" as member values. Well a pratice often done in C. - Axel
Sep 16 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Axel Kittenberger wrote:

 True. :) Ofc, the same can be done in D by declaring a member struct
 inside a class; the class provides the programming interface, while the
 encapsulated struct provides a memory interface.
Yes, thats always possible. But it's then a wrong IS-A, HAS-A relationship. Taken with this aproach in example you don't even need inheritance. You can always use "fathers" as member values. Well a pratice often done in C.
Sounds like you're taking an OOP purist view of things...please correct me if I'm mistaken. OOP-purist isn't bad, so let's define this "interface" class in what (I think) might make good OOP sense. * The struct IS-A memory interface of type X. * The class IS-A program interface of type X-int that HAS-A memory interface of type X. I understand that in C++ you had the convenience of encapsulating the memory and program interfaces into a single type. But I still like the fact that the two are separated. My types tend to start out as glorified structs that slowly migrate into more and more complex classes. D would force a more rigid distinction. Hmmm...repeating myself. Probably time to step out of this before it gets too repetitive and flamy... -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Sep 17 2001
next sibling parent Axel Kittenberger <axel dtone.org> writes:
Russ Lewis wrote:

 Axel Kittenberger wrote:
 
 True. :) Ofc, the same can be done in D by declaring a member struct
 inside a class; the class provides the programming interface, while the
 encapsulated struct provides a memory interface.
Yes, thats always possible. But it's then a wrong IS-A, HAS-A relationship. Taken with this aproach in example you don't even need inheritance. You can always use "fathers" as member values. Well a pratice often done in C.
Sounds like you're taking an OOP purist view of things...please correct me if I'm mistaken. OOP-purist isn't bad, so let's define this "interface" class in what (I think) might make good OOP sense. * The struct IS-A memory interface of type X. * The class IS-A program interface of type X-int that HAS-A memory interface of type X. I understand that in C++ you had the convenience of encapsulating the memory and program interfaces into a single type. But I still like the fact that the two are separated. My types tend to start out as glorified structs that slowly migrate into more and more complex classes. D would force a more rigid distinction. Hmmm...repeating myself. Probably time to step out of this before it gets too repetitive and flamy...
Well I agree it's just a matter of taste, and anyone including walter can do as he likes. Personally I tended also to tell people programming C++, -always- use classes even if you're at first thinking of a struct. It's proparle in cases of evolving software, I agree in case of application pre-designed completly on board first this does not apply, but in cases where projects just grow (often the case in opensource) having always classes usually yields to a better overall programming style. Since people will later think, man for this "struct" I could use a static handling routing for, or this "struct" completly takes over all elements of this one, so let's make it a child, if people do structs in C++ code also when they first think they apply the net result is usally a silent fall back to the pseudo-OO-C-programming-style. "Parents" as field member structs, and field function pointers instead of OO member functions.
Sep 17 2001
prev sibling parent reply a <a b.c> writes:
Russ Lewis wrote:
 I understand that in C++ you had the convenience of encapsulating the memory
 and program interfaces into a single type.  But I still like the fact that the
 two are separated.  My types tend to start out as glorified structs that slowly
 migrate into more and more complex classes.  D would force a more rigid
 distinction.  Hmmm...repeating myself.  Probably time to step out of this
 before it gets too repetitive and flamy...
Not to blow on the flames, but would the rigid distinction get in the way of some evolutionary development models? Last I heard that was still a good thing. (Sure you should periodically consider redoing parts from scratch but not all the time.) The lack of separation in C++ also allowed programmers to add methods to the C structures without impacting their use in C calls. I always thought that was pretty nifty. Dan
Sep 17 2001
parent reply Russ Lewis <russ deming-os.org> writes:
a wrote:

         Not to blow on the flames, but would the rigid distinction get in the
 way of some evolutionary development models?  Last I heard that was
 still a good thing.  (Sure you should periodically consider redoing
 parts from scratch but not all the time.)
You can evolve from a struct to a class. Simply leave the members as public members (while adding functions and/or member functions) or turn the members into gettor/settor properties.
         The lack of separation in C++ also allowed programmers to add methods
 to the C structures without impacting their use in C calls.  I always
 thought that was pretty nifty.
I don't understand...I don't think that it's legal to define member functions in C, right? How could you have cross-compatibility? (Except by derivation...) -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Sep 17 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 I don't understand...I don't think that it's legal to define member
 functions in C,
 right?  How could you have cross-compatibility?  (Except by derivation...)
struct arg { int a; static int add(); }; is allowed in C++, you could add member functions even to structs, altough they had to be public and static. BTW, don't take this example too worldly, might not compile, I didn't try it out, nor did I ever use this feature.
Sep 18 2001
parent Russ Lewis <russ deming-os.org> writes:
Axel Kittenberger wrote:

 struct arg {
    int a;
    static int add();
 };

 is allowed in C++, you could add member functions even to structs, altough
 they had to be public and static. BTW, don't take this example too worldly,
 might not compile, I didn't try it out, nor did I ever use this feature.
Actually, C++ is much more flexible than that. You can make non-public, non-static members of structs. The only difference between struct and class in C++ is that class defaults to private protection while struct defaults to public. Thus, struct { private: ...... } is the same as a class definition. At least, that's how I understand it. Anybody want to contradict me? My question was about how you would interact with C; if you declare a member function (even public-static) that won't work in C. However, you could do the following: struct Cstruct { ... } class CppClass : private Cstruct { ... } As long as the C file never included the header that declared class CppClass, that would work.
Sep 18 2001
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I don't agree that structs should prohibit member functions.  Seems a
pointless, counterproductive restriction.  I do think that virtual member
functions should be prohibited, but without any member functions on a struct
it is going to be quite the PITA to make any kind of high-performance vector
class.  I don't know if you can inherit from a struct... if you can't, then
there is no possibility of virtuals anyway.

Let's promote the coupling of data and methods.  Allow structs to have
member functions.  Even ctors and dtors!

Sean

"Russ Lewis" <russ deming-os.org> wrote in message
news:3BA21C83.481E231F deming-os.org...
 Axel Kittenberger wrote:

 I think it's an old asked question, now what the difference between a
 struct and a public-only class? Do we need structs after all?
In C++, there wasn't any difference - in fact, you could declare private members of a struct. I think that Walter has done a Good Thing by separating the two in D. Key differences (as I understand them): * No member functions of any kind in structs (and therefore no vtable) * All members public in structs * Structs can be created on the stack; all class objects are created on the heap * Specified alignment possible in structs, not in classes I like this because it makes a separation between a hardware-like type (struct) which is simply a mapping of a conglomeration of types over a certain range of memory and a OOP-like type (class) which is a high-level programming abstraction designed to facilitate good and easy programming. This allows the program to have low-overhead access to hardware (a key feature of C) or to subroutines from other languages while still allowing high-level OO design.
Oct 18 2001
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Sean L. Palmer" wrote:

 I don't agree that structs should prohibit member functions.  Seems a
 pointless, counterproductive restriction.  I do think that virtual member
 functions should be prohibited, but without any member functions on a struct
 it is going to be quite the PITA to make any kind of high-performance vector
 class.  I don't know if you can inherit from a struct... if you can't, then
 there is no possibility of virtuals anyway.

 Let's promote the coupling of data and methods.  Allow structs to have
 member functions.  Even ctors and dtors!
This is an interesting point. Removing virtuals means that there is no need for a vtable...thus, adding member functions adds to the functional code in the compiled image, and does not interfere with struct's binary-mapping nature. I would agree with this if there was consensus that there would not be confusion between structs and classes. If users are used to automatic (undeclared) virtual functions in classes, will the non-virtual nature in structs cause confusion? -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Oct 18 2001
parent Russell Borogove <kaleja estarcion.com> writes:
Russ Lewis wrote:
 This is an interesting point.  Removing virtuals means that there is no need
for
 a vtable...thus, adding member functions adds to the functional code in the
 compiled image, and does not interfere with struct's binary-mapping nature.
Ah, here's the thing we were overlooking: all member functions are virtual in D. Obviously, that rule could be altered for struct, but at the cost of complicating the language definition. -RB
Oct 21 2001
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
"Sean L. Palmer" wrote:
 
 I don't agree that structs should prohibit member functions.  Seems a
 pointless, counterproductive restriction.  I do think that virtual member
 functions should be prohibited, but without any member functions on a struct
 it is going to be quite the PITA to make any kind of high-performance vector
 class.  I don't know if you can inherit from a struct... if you can't, then
 there is no possibility of virtuals anyway.
 
 Let's promote the coupling of data and methods.  Allow structs to have
 member functions.  Even ctors and dtors!
The only major point I have against your case is that the "no virtuals" restriction on structs seems more arbitrary than the "no member functions" restriction (even though it's not, particularly). It seems that Walter's intent with D-structs is to encourage their use only when byte-accurate layout is important, and to this end, I accept the arbitrary restrictions.[1] You can still encapsulate your struct manipulations, class-wise, using composition instead of inheritance: struct _hardware_registers_ { ... }; class HardwareAccess { public: void DiddleSomeRegisters( void ); ... private: _hardware_registers_* m_Registers; ... }; This isn't particularly arduous. You can even make the pointer to the registers a class-static if that's advantageous. -RB [1] There's some weak analogy here of the Unix tradition of giving root only the sh shell rather than any of the fancy shells -- you're doing something out of the ordinary, so it's kept deliberately uncomfortable so you stay alert.
Oct 18 2001
next sibling parent reply a <a b.c> writes:
Russell Borogove wrote:
 
 "Sean L. Palmer" wrote:
 I don't agree that structs should prohibit member functions.  Seems a
 pointless, counterproductive restriction.  I do think that virtual member
 functions should be prohibited, but without any member functions on a struct
 it is going to be quite the PITA to make any kind of high-performance vector
 class.  I don't know if you can inherit from a struct... if you can't, then
 there is no possibility of virtuals anyway.

 Let's promote the coupling of data and methods.  Allow structs to have
 member functions.  Even ctors and dtors!
The only major point I have against your case is that the "no virtuals" restriction on structs seems more arbitrary than the "no member functions" restriction (even though it's not, particularly).
Virtual functions and polymorphism in general have a performance and memory penalty associated with them. Member functions are merely an organizational tool that helps encourage the development better APIs for dealing with a datatype, making the use and maintenance of the type safer.
 It seems that Walter's intent with D-structs is to encourage
 their use only when byte-accurate layout is important, and to
 this end, I accept the arbitrary restrictions.[1]
I took it as the bare bone minimum to allow compatibility with C binaries.
 You can still encapsulate your struct manipulations, class-wise,
 using composition instead of inheritance:
 
 struct _hardware_registers_
 {
    ...
 };
 
 class HardwareAccess
 {
 public:
    void DiddleSomeRegisters( void );
    ...
 
 private:
    _hardware_registers_*   m_Registers;
    ...
 
 };
 
 This isn't particularly arduous. You can even make the pointer
 to the registers a class-static if that's advantageous.
Actually, it struck me as one of those situations were the technology is there to make it easier on you, but some egghead either decided that the unwashed massed weren't to be trusted with such powerful features or that nobody really needs to do that anyway. It would be nice to be able to wrap a nice set of member functions around the return value of a file stat, but alas there are bigger battles to fight.
 [1] There's some weak analogy here of the Unix tradition of
 giving root only the sh shell rather than any of the fancy
 shells -- you're doing something out of the ordinary, so it's
 kept deliberately uncomfortable so you stay alert.
Funny, my Linux systems gave root bash. I have a nasty habit of giving him tcsh where ever I go. I probably wouldn't have replied, but I saw this statement and it reminded me of C++'s casts. The committee had the same reasoning you did. I've always felt I and everyone else who has had to do a cast in C++ deserved an apology from someone for C++'s casts. Dan
Oct 18 2001
parent Russell Borogove <kaleja estarcion.com> writes:
a wrote:
 
 Russell Borogove wrote:
 The only major point I have against your case is that the "no
 virtuals" restriction on structs seems more arbitrary than the
 "no member functions" restriction (even though it's not,
 particularly).
Virtual functions and polymorphism in general have a performance and memory penalty associated with them. Member functions are merely an organizational tool that helps encourage the development better APIs for dealing with a datatype, making the use and maintenance of the type safer.
I agree; there's a certain high-level programming mentality that isn't concerned with performance and memory penalties, though, which is why I say that the no-virtuals rule "seems" arbitrary.
 [1] There's some weak analogy here of the Unix tradition of
 giving root only the sh shell rather than any of the fancy
 shells -- you're doing something out of the ordinary, so it's
 kept deliberately uncomfortable so you stay alert.
Funny, my Linux systems gave root bash. I have a nasty habit of giving him tcsh where ever I go. I probably wouldn't have replied, but I saw this statement and it reminded me of C++'s casts. The committee had the same reasoning you did. I've always felt I and everyone else who has had to do a cast in C++ deserved an apology from someone for C++'s casts.
Let me clarify that this isn't necessarily _my_ reasoning. -RB
Oct 19 2001
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Russell Borogove wrote:

 You can still encapsulate your struct manipulations, class-wise,
 using composition instead of inheritance:

 struct _hardware_registers_
 {
    ...
 };

 class HardwareAccess
 {
 public:
    void DiddleSomeRegisters( void );
    ...

 private:
    _hardware_registers_*   m_Registers;
    ...

 };

 This isn't particularly arduous. You can even make the pointer
 to the registers a class-static if that's advantageous.
Really, there's no reason the compiler can't allow direct inheritance of structs into classes (though obviously not vice-versa). -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Oct 19 2001
parent reply a <a b.c> writes:
Russ Lewis wrote:

 Really, there's no reason the compiler can't allow direct inheritance of
structs
 into classes (though obviously not vice-versa).
Well, structs are supposed to preserve member organization in memory. Inheritance would suggest that you are going to preserve that layout so it can still be passed to function that expect the C layout. Classes in D do not promise to preserve to maintain data layout for optimization reasons. This type of inheritance would provide a screwy end run around the optimization. Also, most OO infrastructures put some header info (a vtable) in the class to help with polymorphism. This could make compiler issues more complicated that Walter might like. Neither of these are show stoppers really, but they seem to fly in the face of what Walter planned for D. Dan
Oct 19 2001
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
a wrote:

 Russ Lewis wrote:

 Really, there's no reason the compiler can't allow direct inheritance of
structs
 into classes (though obviously not vice-versa).
Well, structs are supposed to preserve member organization in memory. Inheritance would suggest that you are going to preserve that layout so it can still be passed to function that expect the C layout. Classes in D do not promise to preserve to maintain data layout for optimization reasons. This type of inheritance would provide a screwy end run around the optimization. Also, most OO infrastructures put some header info (a vtable) in the class to help with polymorphism. This could make compiler issues more complicated that Walter might like. Neither of these are show stoppers really, but they seem to fly in the face of what Walter planned for D.
From a theorhetical programmer sense (where I normally come from), you're right. However, in a technical sense I don't think it's a problem. My understanding is that in inheritance, the base class is included into the derived one as a complete, intact element. Then the various additional member variables and vtable entries would be added around it. In that sense, it's no problem to derive classes from structs. The compiler includes the struct as-is, directly as a (unnamed) member of the class. Accesses to its data (or member variables) access the member struct variable; others (declared by the class) obviously access other elements of the class. -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Oct 19 2001
prev sibling next sibling parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
A known common class could have meta-information and meta-functionality such
as persistence, it's really handy. --Kent

"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:9nmtve$280a$1 digitaldaemon.com...
 Why have a common base class 'object'? There is nothing common in 'date'
and
 'point'.

 Guess most of SI v/s MI discussion stems as the language has this common
 base class built in.
Sep 12 2001
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
It is persistance, where the common base class causes problems of M/I.
Maybe, the persistance should be handled by the language itself, as it knows
the class information about the object being streamed out. What is the need
to carry the meta-information with each instance of the object?


Kent Sandvik <sandvik excitehome.net> wrote in message
news:9nobbi$6i$1 digitaldaemon.com...
 A known common class could have meta-information and meta-functionality
such
 as persistence, it's really handy. --Kent

 "Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
 news:9nmtve$280a$1 digitaldaemon.com...
 Why have a common base class 'object'? There is nothing common in 'date'
and
 'point'.

 Guess most of SI v/s MI discussion stems as the language has this common
 base class built in.
Sep 12 2001
parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:9nplbh$nsf$2 digitaldaemon.com...
 It is persistance, where the common base class causes problems of M/I.
 Maybe, the persistance should be handled by the language itself, as it
knows
 the class information about the object being streamed out. What is the
need
 to carry the meta-information with each instance of the object?
Well, maybe Multiple Inheritance is not needed at all, I never use it myself, encapsulation takes care of that. But having a way to enforce a way to have a default protocol for persistence is very important, otherwise the concept of saving the state as XML data, and retrieve it later, even in system, it would provide really interesting solutions. Now this is outside the language scope, more of the runtime, but having a common Object with some real rules would make something like this a reality, same with introspection for smart GUI builders and so forth. --Kent
Sep 13 2001
parent Charles Hixson <charleshixsn earthlink.net> writes:
Kent Sandvik wrote:

 "Rajiv Bhagwat" <dataflow vsnl.com> wrote in message 
news:9nplbh$nsf$2 digitaldaemon.com...

 It is persistance, where the common base class causes
 problems of M/I. Maybe, the persistance should be handled
  by the language itself, as it ...
Well, maybe Multiple Inheritance is not needed at all, I never use it myself, encapsulation takes care of that. But having a way to enforce a way ...
There are generally other possible ways to handle the problems that multiple inheritance is usually used to handle. How much work those other ways take depends on what help the language provides. If one has fine-grained control of forwarding, and also coarse-grained forwarding, then interfaces and forwarding can combine to give almost all of the benefits (and a few extra). To be a little less abstract: Class Bird Wing wing_style; Leg leg_style; Forward /^Wing*/ and not /WingTip/ to wing_style; Forward /^Leg*/ to leg_style; I suppose that one could require that each particular method to be forwarded be listed separately, but then the amount of work required has significantly increased. And, of course, in Java one has to not only list all of the methods to be forwarded, one even has to write a wrapper for each one. Quite annoying. And error prone. (Changes don't happen locally, but echo through the program.) Whether a full regular expression parser is needed there, well, probably not. On the other hand, it's been done, and the source code is available (in the OpenBSD Unix tree is nowhere else). So how much is gained by using a restricted form?
Sep 17 2001
prev sibling next sibling parent reply Chris Friesen <cfriesen nortelnetworks.com> writes:
Rajiv Bhagwat wrote:
 
 Why have a common base class 'object'? There is nothing common in 'date' and
 'point'.
Hmm... how about stuff like: size the fact that it *is* a class type a method to print the class contents nicely formatted less generally, they could both be sortable There are almost certainly other things that would be useful for many classes. -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen nortelnetworks.com
Sep 12 2001
next sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
'size' does not differ for each object of a class, so need not be carried
with each one.

Same goes with the sorting order etc. Only the data belonging to each object
should be carried with it, nothing extra. One pointer, to the vtable of the
class, is the only additional thing required - that too if the class has
virtual methods.

-- Rajiv


Chris Friesen <cfriesen nortelnetworks.com> wrote in message
news:3B9FC267.9A396BF nortelnetworks.com...
 Rajiv Bhagwat wrote:
 Why have a common base class 'object'? There is nothing common in 'date'
and
 'point'.
Hmm... how about stuff like: size the fact that it *is* a class type a method to print the class contents nicely formatted less generally, they could both be sortable There are almost certainly other things that would be useful for many
classes.
 --
 Chris Friesen                    | MailStop: 043/33/F10
 Nortel Networks                  | work: (613) 765-0557
 3500 Carling Avenue              | fax:  (613) 765-2986
 Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com
Sep 12 2001
parent "Anthony Steele" <asteele nospam.iafrica.com> writes:
"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:9nplbj$nsf$3 digitaldaemon.com...
 'size' does not differ for each object of a class, so need not be carried
 with each one.
Right it shouldn't. It should be related to the type, not the instance. However it is impossible (or much much harder) to write a generic container of "objects" if they don't all have a common base class, however lightweight. This is part of the reason why it is a good idea. That lightweight generic base class should at least allow you to ask: - How big is an instance (this should be a class not instance method) - Is the object in fact of this type (RTTI, is-a test) A generic virtual method on the base class to display any object as a string like Java has is nice but not vital.
Sep 14 2001
prev sibling parent "Rui Ferreira" <t5rui hotmail.com> writes:
There are almost certainly other things that would be useful for many
classes. Careful with this, the concept of a unified base class can lead to software engineering practices where polymorphism turns into a glorified run-time casting mechanism...
Sep 13 2001
prev sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
Rajiv Bhagwat wrote:

 Why have a common base class 'object'? There is nothing common in 'date' and
 'point'.
Not on functional level... From both could be said that they are an 'object' as for which both could be derived from 'object'... <g> Jan
Sep 14 2001
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Oh, then the programmer object can invoke the compiler object sending it the
program object to get the object object <g><g>!

Seriously, people have discussed at length (particularly wrt library
designs - MFC included) about how deriving from a single base class leads to
unfavourable situations. I vaguely remember a reference to Coplien's article
on this subject. I would try to fish out the details later.

-- Rajiv

Jan Knepper <jan smartsoft.cc> wrote in message
news:3BA2100F.5D2F9436 smartsoft.cc...
 Rajiv Bhagwat wrote:

 Why have a common base class 'object'? There is nothing common in 'date'
and
 'point'.
Not on functional level... From both could be said that they are an 'object' as for which both could
be
 derived from 'object'... <g>

 Jan
Sep 14 2001
parent Jan Knepper <jan smartsoft.cc> writes:
Rajiv Bhagwat wrote:

 Oh, then the programmer object can invoke the compiler object sending it the
 program object to get the object object <g><g>!
<g>
 Seriously, people have discussed at length (particularly wrt library
 designs - MFC included) about how deriving from a single base class leads to
 unfavourable situations.
It's all a matter of design is what I think... For some functional designs it is favourable to derive from a single base class. For others it is not. I don't think I have complete application around with all classes derived from one single base class. I however do have certain functional implementation that do for the reason that it is very favourable in that situation... <g> Jan
Sep 15 2001