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