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.

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.

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.
>
>
>

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

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.
>

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.
> >
> >
> >
>
>

'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

>>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...

"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 there will be multiple versions, all different. Something I like in C# is the concept of saving the state as XML data, and retrieve it later, even in non-C# environments. If the Object model used this as the default state 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

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