Properties and Methods

I'm not sure how the two IML's come out, but I would be
surprised if
either is much more efficient than the other.  Fact is,
unless you call
the methods many times the difference in performance would
be
negligible.
The real object oriented benefit of using Get/Set accessors
(as opposed
to two separate methods) is in their usage.

Using the Person1 class:
Person1 me = new Person1();
// To set the name:
me.SetFirstname("David");
// To get the name:
Console.Writeline(me.GetFirstName());

Using the Person2 class:
Person2 me = new Person2();
// To set the name:
me.FirstName = "David";
// To get the name:
Console.Writeline(me.FirstName);

The second option is more readable, so more supportable.  It
looks
tidier, so makes you, as the developer, look more
professional.

But what about Person3?

public class Person3
{
	public string FirstName = "";
}

Usage of this class is exactly the same as Person2.  And the
class was
quicker to develop.  Person3 WILL run more efficiently than
Person2, but
Person3 has a limitation:  there's no intermittent code
that can amend
the property value before setting or getting it.

David Bridge


-----Original Message-----
From: CSDevelopersgooglegroups.com
[mailto:CSDevelopersgooglegroups.com] On Behalf Of
themanfromsql
Sent: 26 February 2006 15:46
To: C# Developers
Subject: Properties and Methods


This is a question that I've had knocking around in my head
for a
while.

Here are two Person classes:

public class Person1
{
	private string _firstName = "";

	public void SetFirstName(string firstName)
	{
		this._firstName = firstName;
	}

	public string GetFirstName()
	{
		return this._firstName;
	}

}


public class Person2
{
	private string _firstName = "";

	public string FirstName
	{
		get
		{
			return this._firstName;
		}

		set
		{
			this._firstName = value;
		}
	}

}


As you can see, the first class contains two methods that
are used to
set and get the first name of the Person object.  The second
class
contains a single property FirstName with a getter and
setter.

For the moment let's put aside all questions of getters and
setters
being evil (I do agree with Holub that there should be a
justifiable
reason for exposing a property for reading or writing. 
Let's assume
that there is a valid reason for exposing this property).

My question has to do with the performance of these two
classes and how
the two convert into IL.  What's the difference?  Is there
a
performance difference?  Is there a difference in the
Intermediate
Language?  Is there a perceived benefit to using a property
here rather
than two methods?



************************************************************
********** 
Please visit the official ITV website at www.itv.com
for the latest company news.

This email and any files transmitted are confidential and
intended 
solely for the use of the individual or entity to which they
are 
addressed. If you have received this email in error, please
notify 
postmasteritv.com 

Thank you.
************************************************************
**********

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "C# Developers" group.
To post to this group, send email to CSDevelopersgooglegroups.com
To unsubscribe from this group, send email to
CSDevelopers-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/CSDevelopers
-~----------~----~----~----~------~----~------~--~---

Hi All

   Here's my time to decry what I consider evil myself with
regards to
.NET development. =>  Compiler optimization.  When
compiling into IL
code, your source code is sent through a optimizer. You
cannot leverage
your years of experience and OS understanding to write sleek
code
that's fast and efficient, the compiler will pretty much
ignore your
efforts and send the whole thing through an optimization
process.  Now,
the rookie with 6 months experience will write code that
just as
efficient as the vet with 10 years experience.  Good thing?
for the
company sure.  But as developers we are brought down to the
level of
the lowest common denominator.  Besides, we are supposed to
trust
Microsoft, right?  We couldn't possibly do a better job of
optimization
than the built in optimizer.  Seems I heard that same claim
with SQL
server optimization when MS frowns upon query hints.  I have
seen
myself a hint consistently out perform  the sql compiler. 
So,
theoretically, it is possible in some instances that the
emitted  IL
code is less efficient than the original source.  Rant
ended.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "C# Developers" group.
To post to this group, send email to CSDevelopersgooglegroups.com
To unsubscribe from this group, send email to
CSDevelopers-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/CSDevelopers
-~----------~----~----~----~------~----~------~--~---

The compiler doesn't catch everything. Infact, most of the
changes made
are things that you really can't specify in the higher
level languages.
Besides, c/c++ have been optomized for years. They aren't
brilliant,
they just simplify a few things. Of course, you are allways
welcome to
unroll all of your loops manually, should you choose.

Whats nice about the clr optomizer is the fact that it is
optimized
twice. Once when you compile to il, and again when the clr
jit compiles
it to native code. That makes way for many interresting
possablilties,
like inlining functions across dynamically linked
assemblies. That type
of change couldn't be made by a skilled programmer, unless
he compiled
a different version for every target machine, and then
recompiled
everytime a linked assembly is edited.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "C# Developers" group.
To post to this group, send email to CSDevelopersgooglegroups.com
To unsubscribe from this group, send email to
CSDevelopers-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/CSDevelopers
-~----------~----~----~----~------~----~------~--~---