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.
--
Gaemic! 21 9746
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.
--
Regards,
Peter Jausovec
( http://blog.jausovec.net)
"Gaemic" <Ga****@discussions.microsoft.com> je napisal v sporočilo
news:AA**********************************@microsof t.com ... 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. -- Gaemic!
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Gaemic" <Ga****@discussions.microsoft.com> wrote in message
news:AA**********************************@microsof t.com... 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. -- Gaemic!
On Wed, 8 Dec 2004 07:37:01 -0800, Gaemic wrote: 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.?
--
Tom Porterfield
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> 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 !!!
"Tom Porterfield" wrote:
On Wed, 8 Dec 2004 07:37:01 -0800, Gaemic wrote:
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.? -- Tom Porterfield
Gaemic <Ga****@discussions.microsoft.com> wrote: 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 !!!
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...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
On Wed, 8 Dec 2004 10:25:02 -0800, Gaemic wrote: 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.
--
Tom Porterfield
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Oa**************@tk2msftngp13.phx.gbl... 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.
"Tom Porterfield" <tp******@mvps.org> wrote in message
news:13****************@tpportermvps.org... On Wed, 8 Dec 2004 07:37:01 -0800, Gaemic wrote:
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.?
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.
On Thu, 9 Dec 2004 23:41:34 -0800, Mike Schilling wrote: 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?
--
Tom Porterfield
"Tom Porterfield" <tp******@mvps.org> wrote in message
news:oz***************@tpportermvps.org... On Thu, 9 Dec 2004 23:41:34 -0800, Mike Schilling wrote:
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?
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?
> 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.
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OZ**************@TK2MSFTNGP09.phx.gbl... 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.
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.
On Sat, 11 Dec 2004 08:11:19 -0800, Mike Schilling wrote: 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.
--
Tom Porterfield
"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:u0**************@TK2MSFTNGP10.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in message news:OZ**************@TK2MSFTNGP09.phx.gbl... > 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.
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. <jv************@yahoo.com> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Ravichandran J.V. <jv************@yahoo.com> wrote: 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.
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. 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.
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uR**************@TK2MSFTNGP14.phx.gbl... 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.
It's a bit late to be deciding that :-)
"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in message news:uR**************@TK2MSFTNGP14.phx.gbl... 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.
It's a bit late to be deciding that :-)
I would argue that Java compatibilty was likely near the bottom of the
compatibility pile. The langauges are similar, but I do not think C# was a
blind Java clone and it certainly didn't choose the java way for the sake of
java compatibility whenever a crossroads was met. ;) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ville Vainio |
last post by:
Pythonic Nirvana - towards a true Object Oriented Environment
=============================================================
IPython (by Francois Pinard) recently (next release - changes are...
|
by: Bijay Kumar |
last post by:
Hi Guys,
I was going through the source code of Object.cs in rotor. What I found is
Equals() implemented as follows:
public extern virtual bool Equals(Object obj);
What I don't...
|
by: monkey king |
last post by:
I have a given dll file(PDFCreator.dll) - probably generated by VC++.
I want to use its method(PDFCreator()) in dotNet environment. It works
well in WindiowsApplication, but bad in WebApplication...
|
by: DrUg13 |
last post by:
In java, this seems so easy. You need a new object
Object test = new Object() gives me exactly what I want.
could someone please help me understand the different ways to do the
same thing in...
|
by: muralidharan |
last post by:
WebForm1.aspx Code:
<%@ Register TagPrefix="ComponentArt" Namespace="ComponentArt.Web.UI"
Assembly="ComponentArt.Web.UI" %> <ComponentArt:TreeView
id="TreeView1" Height="520"...
|
by: Bijay Kumar |
last post by:
Hi Guys,
I was going through the source code of Object class (Object.cs in rotor). What I found is
Equals() implemented as follows:
public extern virtual bool Equals(Object obj);
What...
|
by: Poewood |
last post by:
Okay here are four classes for a pocket pc program: Input, fpositional,
ComboBoxArray and TextBoxArray. The "input" class is the form. I use the
fpositional class to handle most of the functions...
|
by: Kevin Phifer |
last post by:
Ok, before anyone freaks out, I have a solution I need to
create that gathers content from maybe different places.
Each one can return a <form> in the html, so its the
classic can't have more than...
|
by: Matthew |
last post by:
I have a nice little Sub that saves data in a class "mySettings" to an XML
file.
I call it like so:
Dim mySettings As mySettings = New mySettings
mySettings.value1 = "someText"
mySettings.value2...
|
by: ST |
last post by:
Hello everyone, Can anyone help me with this error above when I debug my web
app project in vstudio.net?? I can't figure it out! It was working fine for
months, and now all of a sudden it's not!!...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |