1

If I have "Object" as the top level class, then I have various interfaces, ISomething, ISomethingB, ISomethingC, then I have Class x,y,z, all ultimately deriving from the class Object (these subclasses don't have to derive from each other), wouldn't me having one class at the top like "Object" in .NET lead to, or possibly lead to, type safety issues like:

Object myText = "Johnny";

instead of

string myText = "Johnny";

If I used the former, does that mean I could do something like this?

Object myText = "Johnny";
double someValue = 0.0;
someValue = "Johnny";

That doesn't make sense, but is it legal?

Should there always be a main object at the type of a class hierarchy like in .NET from which all others derive?

As an example, take a school application.

Students, Staff, Classes, Grades, and so on.

Should there be a top level object like "School" and have all of those classes or interfaces below it? I can't think of why I'd do that. Why not have four or five top level classes that do not intersect anywhere?

Edit: I have read, Why all classes in .NET globally inherits from Object class?

12
  • 2
    What is it about the question you linked along with its answer that you don't feel answers your question?
    – JeffO
    Nov 7 '16 at 15:05
  • 2
    Not sure what you're going for but your snippet won't compile let alone run. someValue is of type double, and will not be allowed an assignment to a string literal; neither will it be allowed an assignment to myText.
    – Erik Eidt
    Nov 7 '16 at 15:08
  • 1
    First, your snippet declares myText but doesn't use it. Next, it assigns a string literal to a variable whose type is double. That won't fly. Just because they/all share a common base type Object doesn't mean you can do whatever you want. You still have to follow the basic type system rules, and that means passing compile time checks, and runtime checks.
    – Erik Eidt
    Nov 7 '16 at 15:31
  • 1
    The compile time checks are done using the type information available at compile time. The runtime checks are done using the type information available at runtime. There is a relationship between the information available at compile time and at runtime. Runtime always a totally accurate picture of various types of entities. However, sometimes compile time does as well, and, when compile time doesn't have the complete picture it most often has more information than merely Object. And this enables a certain amount of checking even if the information is a bit imprecise or general.
    – Erik Eidt
    Nov 7 '16 at 15:34
  • 1
    (And when the system knows that the compile time checks were performed and were sufficient, then it can omit many of the runtime checks.)
    – Erik Eidt
    Nov 7 '16 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.