Best Practices: always use new() with objects?

[raylopez99]

Hi,

Best practices question.

When receiving an object passed from another method, is it a good idea
to use a shallow copy with a temporary object received on the RHS
(right hand side of =), or to use a instantiated object to receive the
object on the RHS?

Since I may be using the wrong lingo, to put it more concretely.

FIRST WAY:

void somemethod
{

SomeClass X; //declares X as an object but does not instantiate it

X = Y // where Y is a reference passed by another method of type
SomeClass

// work with X within 'somemethod', and when the method 'somemethod'
ends, X is local and will disappear

}

SECOND WAY:

void somemethod
{
SomeClass X = new SomeClass(); // instantiated X

X = Y

// X will also disappear once void somemethod ends

}

Which is "better"? I say FIRST WAY. Which is safer? Perhaps SECOND
WAY, since it's less likely that X is a null reference, though if Y is
null then X can be null, so you have to check for it anyway.

[Anthony Jones]

"raylopez99" <ra********@yahoo.comwrote in message
news:11**********************@o61g2000hsh.googlegr oups.com...

Hi,

Best practices question.

When receiving an object passed from another method, is it a good idea
to use a shallow copy with a temporary object received on the RHS
(right hand side of =), or to use a instantiated object to receive the
object on the RHS?

Since I may be using the wrong lingo, to put it more concretely.

FIRST WAY:

void somemethod
{

SomeClass X; //declares X as an object but does not instantiate it

X = Y // where Y is a reference passed by another method of type
SomeClass

// work with X within 'somemethod', and when the method 'somemethod'
ends, X is local and will disappear

}

SECOND WAY:

void somemethod
{
SomeClass X = new SomeClass(); // instantiated X

X = Y

// X will also disappear once void somemethod ends

}

Which is "better"? I say FIRST WAY. Which is safer? Perhaps SECOND
WAY, since it's less likely that X is a null reference, though if Y is
null then X can be null, so you have to check for it anyway.

Not sure why you believe avoiding a null reference is safer?

If Y is already inscope why would you want to do X = Y in the first place?

If there is a possibility that Y may be null you should write your code with
that in mind and take an appropriate action if it is. In some cases that
may be to use a new instance of the Y's type but I suspect there will be a
lot of cases where that isn't the right thing to do.

--
Anthony Jones - MVP ASP/ASP.NET

[GlennDoten]

raylopez99 wrote:

Hi,

Best practices question.

When receiving an object passed from another method, is it a good idea
to use a shallow copy with a temporary object received on the RHS
(right hand side of =), or to use a instantiated object to receive the
object on the RHS?

Since I may be using the wrong lingo, to put it more concretely.

FIRST WAY:

void somemethod
{

SomeClass X; //declares X as an object but does not instantiate it

X = Y // where Y is a reference passed by another method of type
SomeClass

// work with X within 'somemethod', and when the method 'somemethod'
ends, X is local and will disappear

}

SECOND WAY:

void somemethod
{
SomeClass X = new SomeClass(); // instantiated X

X = Y

// X will also disappear once void somemethod ends

}

Which is "better"? I say FIRST WAY. Which is safer? Perhaps SECOND
WAY, since it's less likely that X is a null reference, though if Y is
null then X can be null, so you have to check for it anyway.

I'm assuming you mean this:

class SomeClass { }
class FIRST_WAY
{
void somemethod(SomeClass Y)
{
SomeClass X;
X = Y;
}
}
class SECOND_WAY
{
void somemethod(SomeClass Y)
{
SomeClass X = new SomeClass();
X = Y;
}
}

I think the first is the best way to write this. And it can be made even
clearer (or at least one less line of code) like this:

SomeClass X = Y;

This means that X will now hold the same reference that Y holds, so
there are now at least two references to the same object that the GC
will keep track of. When somemethod exits, the reference in X will no
longer hold and the object will have one less reference. And once the
calling code's reference (communicated using Y) goes out of scope then
the object will not have that reference anymore. Assuming nothing else
has a reference to that same object then the GC can get rid of the
object at this point.

The second one doesn't make any sense to me. The first problem I see is
that you may not have the required information to create an instance of
SomeClass from within the somemethod method. And if you do, you simply
needlessly instantiate a SomeClass then immediately free up any
references to it by assigning Y to X and the GC will simply get rid of
the object on its next pass. So you've basically done a big NOOP.

I kinda have a feeling you are trying to ask a different question here,
or I have misinterpreted what you are asking.

--
-glenn-

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

raylopez99 wrote:

Hi,

Best practices question.

When receiving an object passed from another method, is it a good idea
to use a shallow copy with a temporary object received on the RHS
(right hand side of =), or to use a instantiated object to receive the
object on the RHS?

You don't create copies of objects that way in .NET.

Since I may be using the wrong lingo, to put it more concretely.

FIRST WAY:

void somemethod
{

SomeClass X; //declares X as an object but does not instantiate it

X = Y // where Y is a reference passed by another method of type
SomeClass

That will only create a copy of the reference, not a copy of the object.
As Y already is a copy of the reference that you used in the call to
somemethod, it's pointless to make another copy of it.

// work with X within 'somemethod', and when the method 'somemethod'
ends, X is local and will disappear

The variable X is local, but it's referencing the same object as Y and
as the variable you used in the call. The reference X is local, but the
object is not.

}

SECOND WAY:

void somemethod
{
SomeClass X = new SomeClass(); // instantiated X

X = Y

That is even more pointless. You create an instance of the object and
put the reference to it in the X variable. Then you overwrite the
reference with the reference in the Y variable. You have only created an
object that is never used.

// X will also disappear once void somemethod ends

}

Which is "better"? I say FIRST WAY. Which is safer? Perhaps SECOND
WAY, since it's less likely that X is a null reference, though if Y is
null then X can be null, so you have to check for it anyway.

Neither. You are just making a copy of a copy of the reference. That
doesn't protect anything at all.

--
Göran Andersson
_____
http://www.guffa.com

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

raylopez99 wrote:

When receiving an object passed from another method, is it a good idea
to use a shallow copy with a temporary object received on the RHS
(right hand side of =), or to use a instantiated object to receive the
object on the RHS?

Since I may be using the wrong lingo, to put it more concretely.

FIRST WAY:

void somemethod
{

SomeClass X; //declares X as an object but does not instantiate it

X = Y // where Y is a reference passed by another method of type
SomeClass

// work with X within 'somemethod', and when the method 'somemethod'
ends, X is local and will disappear

}

SECOND WAY:

void somemethod
{
SomeClass X = new SomeClass(); // instantiated X

X = Y

// X will also disappear once void somemethod ends

}

Which is "better"? I say FIRST WAY. Which is safer? Perhaps SECOND
WAY, since it's less likely that X is a null reference, though if Y is
null then X can be null, so you have to check for it anyway.

Actually the two codes does the same thing except that the second one
create an object that you do not use for anything.

No difference for null handling.

None of them has anything to do with shallow clone.

Arne

[raylopez99]

On Aug 12, 6:44 am, GlennDoten <[e-mail]:

>
I kinda have a feeling you are trying to ask a different question here,
or I have misinterpreted what you are asking.

--
-glenn-

No, you answered my question glenn.

But I posted this before I realized that in C# there is never any
implicit shallow copying (unlike C++), therefore, SomeClass X = Y; is
somewhat pointless, since you can use Y instead in the body of the
function. However, as I type this I realize that if you pass by value
rather than by reference, that is, if you do NOT use the 'ref'
keyword: void somemethod(ref SomeClass Y) // i.e. DON'T do this, but
rather, as in your example, void somemethod(SomeClass Y), then you can
use SomeClass X = Y; for code clarity, if you do stuff in the method
that returns SomeClass (to give a reader of your code some idea that
you're not returning Y as modified, but X, though one can argue that
the lack of the 'ref' keyword should clue in the reader that this is
the case.

Come to think of it, now that I see C# is like old-fashioned C in that
you are keeping track of passing a pointer (or reference) around, why
would you ever use SomeClass X = Y; ? Just use Y directly in your
method. All this time in C# I've been doing either "FIRST WAY" or,
(rarely, but in a few instances) "SECOND WAY" above, and this has
needlessly been somewhat slowing down my programs, though how much is
debatable with all the stuff going on behind the scenes in C#.NET
anyway.

RL

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

raylopez99 wrote:

But I posted this before I realized that in C# there is never any
implicit shallow copying (unlike C++), therefore, SomeClass X = Y; is
somewhat pointless, since you can use Y instead in the body of the
function.

Right.

However, as I type this I realize that if you pass by value
rather than by reference, that is, if you do NOT use the 'ref'
keyword: void somemethod(ref SomeClass Y) // i.e. DON'T do this, but
rather, as in your example, void somemethod(SomeClass Y), then you can
use SomeClass X = Y; for code clarity, if you do stuff in the method
that returns SomeClass (to give a reader of your code some idea that
you're not returning Y as modified, but X, though one can argue that
the lack of the 'ref' keyword should clue in the reader that this is
the case.

But that doesn't add any clarity. You are just copying the reference,
not the object, so it's still the same object.

If you change the object and return it, you have changed the original
object, which might be confusing as the signature of the method implies
that it should return a copy and leave the original unchanged.

Come to think of it, now that I see C# is like old-fashioned C in that
you are keeping track of passing a pointer (or reference) around, why
would you ever use SomeClass X = Y; ? Just use Y directly in your
method.

Exactly.

All this time in C# I've been doing either "FIRST WAY" or,
(rarely, but in a few instances) "SECOND WAY" above, and this has
needlessly been somewhat slowing down my programs, though how much is
debatable

Not much for the "first way". Another local variable only increases the
stack frame for the method, and that only costs a few bytes of stack
space, there is no extra code for that. The copying of the reference is
just a single instruction, so that doesn't take much time.

If the method is simple enough, the compiler might even be able to
completely optimise the extra variable away, just keeping the reference
in a processor register.

with all the stuff going on behind the scenes in C#.NET
anyway.

Besides the garbage collector, there isn't much going on behind the
scenes in .NET. There is no reference counting, so there is no extra
code added when references are copied, replaced or goes out of scope.
There no extra code added to run destructors when objects become
unreachable.

When you assign a reference, the only thing that happens is that four
bytes (on a 32 bit system) is copied, nothing else. When a reference
goes out of scope, nothing at all happens. I just goes silently into the
night.

[Peter Duniho]

raylopez99 wrote:

Now I'm confused again. Are you saying that local variables indeed
preserve copies of Y, depending on the value of Y during the
"assignment"?

It depends on what you mean specifically. Local variables can be used
to preserve a copy of the _reference_ to the object Y. The object
remains the same, but you can replace the reference with a difference
reference, and as long as you still have a reference to the original
object is available in some other variable, then you can still get to
the original object.

(This is the way it works in C++, since SomeClass X=Y is
actually equivalent to SomeClass X(Y), where the copy constructor is
used for X).

An example:

LocalMethod (SomeClass Y) // pass by value
{

SomeClass X = Y;

// work with and change Y now, i.e. "Y++", etc

SomeClass Z = Y;

//work with and change Y now

SomeClass W = Y;

/*
Are we saying that: X != Z != W; //?!?

No. In that example all of the references still point to the same
original object, and after all the copying of the references, the
references are equal to each other. They are equal with respect to the
reference itself, and so of course the objects to which they refer are
identical as well.

I thought this is contrary to the philosophy of C#?

Wait... I will write a quick demonstration program rather than simply
post...hold on now...
[Ten minutes later...]

I think from your sample program, you see what I'm talking about. But
please feel free to ask for clarification if it's still not clear.

Pete

[raylopez99]

On Aug 13, 10:21 am, Peter Duniho <[e-mail]>
wrote:

raylopez99 wrote:

>

Wait... I will write a quick demonstration program rather than simply
post...hold on now...
[Ten minutes later...]

I think from your sample program, you see what I'm talking about. But
please feel free to ask for clarification if it's still not clear.

Pete

Thanks for that clarification.

RL