object vs System.Object

[Guest]

Some argues that you should not use the C# keyword "object" instead of the
real type System.Object.

What would be the general rule of thumb for choosing one over the other?

Thanks in advanced.

 

[Peter Jausovec]

Hi,

I think that keyword "object" is just an direct alias for System.Object so I
think it's the same if you use object or System.Object.

 

[Nicholas Paldino [.NET/C# MVP]]

Gaemic,

There is no rule of thumb, it's purely personal preference. The two are
exactly the same. "object" is an alias that the C# compiler recognizes for
"System.Object". "System.Object" is not a "real type" compared to "object",
they both are lexical representations of the same type.

It truly doesn't matter what you pick (which one would think implies
that there should be no argument about it, but people are silly like that).

Hope this helps.

 

[Tom Porterfield]

Some argues that you should not use the C# keyword "object" instead of the
real type System.Object.

What would be the general rule of thumb for choosing one over the other?

Thanks in advanced.

C# keyword object and System.Object are the same, the first is just an
alias for the latter. I can think of no reason to use System.Object
instead of object. Do those who argue against the use of object also argue
against the use of int (System.Int32), string (System.String), byte
(System.Byte), bool (System.Boolean), etc.?

 

[Jon Skeet [C# MVP]]

There is no rule of thumb, it's purely personal preference. The two are
exactly the same. "object" is an alias that the C# compiler recognizes for
"System.Object". "System.Object" is not a "real type" compared to "object",
they both are lexical representations of the same type.

It truly doesn't matter what you pick (which one would think implies
that there should be no argument about it, but people are silly like that).

While it doesn't matter for object, it does matter for (say)
Single/float - when you use it in a method name.

While I use the C#-specific keywords everywhere when they're used *as*
keywords, any method names should (IMO) be based on CLR names. For
instance, I'd use ReadSingle over ReadFloat, and ReadInt64 over
ReadLong. This makes the method names language agnostic.

 

[Guest]

Do those who argue against the use of object also argue

against the use of int (System.Int32), string (System.String), byte
(System.Byte), bool (System.Boolean), etc.?

Yes. And what they are arguing about is that the System.xxx will never
changed. But because the aliases (like int) actually points to System.Int32,
nothing says in a future version that "int" could not point to (alias to)
System.Int64 !!!

 

[Jon Skeet [C# MVP]]

Yes. And what they are arguing about is that the System.xxx will never
changed. But because the aliases (like int) actually points to System.Int32,
nothing says in a future version that "int" could not point to (alias to)
System.Int64 !!!

Yes it does - the C# language spec does. If they're not relying on that
to be backwardly compatible (which changing int to point to Int64
wouldn't be) then they shouldn't be trusting the language *at all*.
Who's to say that "null" isn't going to be replaced with "Oojimaflip"?
Only the spec...

 

[Tom Porterfield]

Yes. And what they are arguing about is that the System.xxx will never
changed. But because the aliases (like int) actually points to System.Int32,
nothing says in a future version that "int" could not point to (alias to)
System.Int64 !!!

As Jon points out, the C# spec says it cannot be changed. Who is to say
the System.xxx names won't ever be changed? That argument to me would be
for using the alias. If System.Int32 were changed to System.32bitInteger
the int alias could be updated without having to also change its name.

 

[Mike Schilling]

Gaemic,

There is no rule of thumb, it's purely personal preference. The two
are exactly the same. "object" is an alias that the C# compiler
recognizes for "System.Object". "System.Object" is not a "real type"
compared to "object", they both are lexical representations of the same
type.

It truly doesn't matter what you pick (which one would think implies
that there should be no argument about it, but people are silly like
that).

The other way around. If there were a right answer, the argument would
eventually die down. Since it doesn't matter, the argument can go on
forever.

 

[Mike Schilling]

C# keyword object and System.Object are the same, the first is just an
alias for the latter. I can think of no reason to use System.Object
instead of object. Do those who argue against the use of object also
argue
against the use of int (System.Int32), string (System.String), byte
(System.Byte), bool (System.Boolean), etc.?

I don't argue, but the convention of uppercase Object or Structure vs.
lowercase scalar works for me, and probably for most people coming from a
C++ or Java background.

 

[Tom Porterfield]

I don't argue, but the convention of uppercase Object or Structure vs.
lowercase scalar works for me, and probably for most people coming from a
C++ or Java background.

Hehe, I come from a C++ background. I also happen to type faster using
lower case letters rather than upper case. But more importantly I am not
coding in C++ but rather C# now.

So if you use Object rather than object, do you also use Int32 rather than
int? My point being to ask are you consistent in your usage pattern, or is
your usage based on baggage that you bring from some other programming
language?

 

[Mike Schilling]

Hehe, I come from a C++ background. I also happen to type faster using
lower case letters rather than upper case. But more importantly I am not
coding in C++ but rather C# now.

So if you use Object rather than object, do you also use Int32 rather than
int?

No. As I said, lowercase scalars seem intuitive to me, and, auto-boxing and
"unified type system" notwithstanding, there is a difference between scalars
and structured types.

My point being to ask are you consistent in your usage pattern, or is
your usage based on baggage that you bring from some other programming
language?

I'm bringing baggage from 25 years of software development. How do you
avoid that? Why would you want to?

 

[Daniel O'Connell [C# MVP]]

I'm bringing baggage from 25 years of software development. How do you
avoid that? Why would you want to?

Because some of that baggage will hamper you. Or, if not you, cause trouble
with other people...and if your baggage is causing everyone else problems,
to my mind that is a problem on your part.

Some baggage is a good thing, but not all of it is.

 

[Mike Schilling]

Because some of that baggage will hamper you. Or, if not you, cause
trouble with other people...and if your baggage is causing everyone else
problems, to my mind that is a problem on your part.

Some baggage is a good thing, but not all of it is.

True, but some of it is vital.

In this case, "Object" vs "object" is a silly thing, and the reasons for the
choice hardly matter. Likewise

i++;

vs.

++i;

is of no real importance, and if you find the former more comfortable
because you used to write PDP-11 assembly language, there's no harm done.

But when all those around you are saying "use structs, not objects: they're
faster", and decades of baggage are saying "Use value types for things with
value semantics and reference types for things with reference semantics.
Premature optimization is a sin, and incorrect semantics in the service of
premature optimization is a mortal sin," well, be thankful for the baggage.

 

[Tom Porterfield]

i++;

vs.

++i;

True, like that there isn't much difference. But in the following, there
is a difference:

x = i++;
x = ++i;

And as far as baggage goes, there is good and bad, most good but not all.

 

[Daniel O'Connell [C# MVP]]

True, but some of it is vital.

In this case, "Object" vs "object" is a silly thing, and the reasons for
the choice hardly matter. Likewise

i++;

vs.

++i;

is of no real importance, and if you find the former more comfortable
because you used to write PDP-11 assembly language, there's no harm done.

I agree, in most circumstances(some things, like prefixes on parameters have
to go, comfort or not, but most things are ok). As far as incrementing goes,
I find i++ to make considerably more sense, readability wise, over ++i(that
just doesn't immediatly look like an increment), thus I use i++. I can deal
with both, don't care which is used as long as its usage is correct.

Still, within a single codebase, both of these shoudl be standardized.
Having code that uses Object, object and System.Object is horridly messy.
But as long as it matches the rest of the codebase I could care less what
particular name you use.

But when all those around you are saying "use structs, not objects:
they're faster", and decades of baggage are saying "Use value types for
things with value semantics and reference types for things with reference
semantics. Premature optimization is a sin, and incorrect semantics in the
service of premature optimization is a mortal sin," well, be thankful for
the baggage.

Likewise, I said some is ok, some isn't. My point was that you can't just
keep baggage and expect everyone else to conform to it simply because you
don't feel like learning the platform(in response to "Why would you want
to?"). Forcing baggage strictly for purposes of laziness(like trying to
force some C++ or java idioms onto .NET simply because you think they are
the only way possible) is going to come back and cause trouble somewhere
down the line.

 

[Ravichandran J.V.]

object is simply the class not being qualified with the namespace name.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

 

[Jon Skeet [C# MVP]]

object is simply the class not being qualified with the namespace name.

Not it's not. The class name is "Object" not "object" - C# is case
sensitive, remember. "object" is like "int" - a shorthand which is
C#-specific.

See section 8.2.1 (ECMA numbering) of the C# specification.

 

[Mike Schilling]

Not it's not. The class name is "Object" not "object" - C# is case
sensitive, remember. "object" is like "int" - a shorthand which is
C#-specific.

And whose purpose (like that of "string") I don't understand. "int",
"float", etc. are for C, C++, and Java compatibility. "object" and "string"
are invented names for things that have perfectly good, awfully similar (one
bit away in ASCII or Unicode), and Java-compatible names already.

 

[Daniel O'Connell [C# MVP]]

And whose purpose (like that of "string") I don't understand. "int",
"float", etc. are for C, C++, and Java compatibility. "object" and
"string" are invented names for things that have perfectly good, awfully
similar (one bit away in ASCII or Unicode), and Java-compatible names
already.

Frankly, java compatibilty isn't somethign they should have been designing
for. C and C++ yes, for legacy reasons, but the language kicked away java
and C++ compatibility in a few other ways(like inheritance specifications or
empty method declarations). Simply not providing an alias because no other
langauge with apparent common lineage offered it is a really lacking reason,
IMHO.

Anyway, I would suspect that the reasoning is that object and string are
very commonly used types and by using an alias there is no concern with
namespaces clashing. Its a minor reason, granted, as it would be ill advised
to define your own Object or String class, but is likely the driving force.

There also may have been consistency reasons as well.