Properties (should be simple!)

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there a way to make a property that public can only be set but privately can be read? I've been trying all sorts but can't seem to find an easy solution. I must be making a really simple mistake

Thanks

Marti
 
Not yet (read: whidbey).
You should use pair of get/set methods to achieve this now.
Click to expand...


Really? Where can I read more about whats planned in Whidbey?
Iam especially interested in the changes from .NET framework 1.1 to 1.2.
 
Hi Martin,

Not yet (read: whidbey).
You should use pair of get/set methods to achieve this now.

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Martin said:
Is there a way to make a property that public can only be set but
Click to expand...
privately can be read? I've been trying all sorts but can't seem to find an
easy solution. I must be making a really simple mistake!
 
Martin said:
Is there a way to make a property that public can only be set but
privately can be read? I've been trying all sorts but can't seem to
find an easy solution. I must be making a really simple mistake!
Click to expand...

Nope - the language/CLR designers did (or they were too pushed for
time). Unfortunately you'll have to wait for Whidbey for this
functionality...
 
Hi Martin,

check the code below:

public class Test
{
private int mSomeValue;

private int ReadSomeValue()
{
// -- do whatever you want with the mSomeValue member
}

// -- set only property --
public int SomeValue
{
set { mSomeValue = value; }
}
}



Martin said:
Is there a way to make a property that public can only be set but
Click to expand...
privately can be read? I've been trying all sorts but can't seem to find an
easy solution. I must be making a really simple mistake!
 
codymanix said:
Really? Where can I read more about whats planned in Whidbey?
Iam especially interested in the changes from .NET framework 1.1 to 1.2.
Click to expand...

1) Fire up your Internet browser
2) Navigate to http://www.google.com
3) Enter the word Whidbey in the box and hit the button
 
My preference would have been to use get and set methods but this is part of an assignment for a lecturer who has asked that we use properties, seemed a little crazy to me. I have currently found a bit of a way around it, but I keep getting stack overflow exceptions when executing this method

private AddressList InternalDataList

public AddressList DataLis

se
{
InternalDataList = value
DataList = value




-------------------------------------------------------------------------------------
The code calling the property that is invoking the stack overflow is below

static void Main()

Application.Run(new Form1())


private void Form1_Load(object sender, System.EventArgs e

AddressList myAddressList = new AddressList()
AddressData myAddress = new AddressData(1, "Meadow Brow", "Alderley Edge", "Cheshire", "SK9 7XD")
myAddressList.Add(myAddress.getPostcode(), myAddress)
myAddress = new AddressData(11, "Grosvenor Place", "Grosvenor Street", "Manchester", "M1 7HR")
myAddressList.Add(myAddress.getPostcode(), myAddress)
adcControl1.DataList = myAddressList


Any ideas?

And thanks for your help so far, I'll make a point that this is a **** way of doing this in my report!
 
Martin said:
My preference would have been to use get and set methods but this is
part of an assignment for a lecturer who has asked that we use
properties, seemed a little crazy to me. I have currently found a bit
of a way around it, but I keep getting stack overflow exceptions when
executing this method:

private AddressList InternalDataList;

public AddressList DataList
{
set
{
InternalDataList = value;
DataList = value;

}
}
Click to expand...

Yes, you would get an overflow exception - you're calling the setter
again within itself (DataList=value).

A way to avoid making that kind of mistake is to use a naming
convention which distinguishes properties from fields.
 
Yes, you would get an overflow exception - you're calling the setter
again within itself (DataList=value).

A way to avoid making that kind of mistake is to use a naming
convention which distinguishes properties from fields.
Click to expand...


I _hate_ underscores for private fields. Why doesn't the C# give a warnung
when it encounters an unconditional
recursion like:

public Foo ()
{
get{ return Foo; } // instead of return foo
}

OnFoo()
{
this.Foo(); // instead of base.Foo
}

Iam also wondering why things like a=a (selfassignment) get compiled without
even a warning.

This kinds of errors are the most frequent that are happening to me, since
c# doesn't normally need pointers which where in c++ the most feared
mistakes.
 
codymanix said:
I _hate_ underscores for private fields.
Click to expand...

Me too. I just use casing to distinguish.
Why doesn't the C# give a warnung when it encounters an unconditional
recursion like:

public Foo ()
{
get{ return Foo; } // instead of return foo
}
Click to expand...

I believe it's quite difficult to do that in a generalised way, to be
honest...
OnFoo()
{
this.Foo(); // instead of base.Foo
}

Iam also wondering why things like a=a (selfassignment) get compiled without
even a warning.
Click to expand...

That needn't be a no-op, of course, although it's likely to be a bug,
and a warning would be nice.
This kinds of errors are the most frequent that are happening to me, since
c# doesn't normally need pointers which where in c++ the most feared
mistakes.
Click to expand...

I think I've only actually got to the stage of running code with a bug
like either of the above in *once* in C#.
 
Why doesn't the C# give a warnung when it encounters an unconditional
I believe it's quite difficult to do that in a generalised way, to be
honest...


That needn't be a no-op, of course, although it's likely to be a bug,
and a warning would be nice.
Click to expand...


Provide me one example where calling the same method/property without
condition will not lead to an stackoverflowexception, this is impossible.

a selfassignment is,if it is not a property always a no-op. but most times
it happens when you have something like that:

Foo(int tmpVaar)
{
this.tmpVar=tmpVar;
}

Note the typo in the method signature. This way, this.tmpVar=tmpVar is a
selfassignment.
 
codymanix said:
Provide me one example where calling the same method/property without
condition will not lead to an stackoverflowexception, this is impossible.
Click to expand...

Without condition, that's true. And I dare say the compiler could pick
up on the simplest cases:

get
{
return PropertyName;
}
set
{
PropertyName = value;
}

But there are any number of cases which are "quite similar" and which
are obviously going to overflow but which the compiler would have a
hard time picking up. I can see the argument that if it's not going to
do a pretty thorough job, it shouldn't try to do the job at all.
a selfassignment is,if it is not a property always a no-op.
Click to expand...

No it's not.

a = a;

could change the value of a, if there are multiple threads running:

Thread 1: Thread 2:
Read value of a
Assign different value to a
Write previously written
value back to a

If thread 1 omits its steps, the result is different.
but most times
it happens when you have something like that:

Foo(int tmpVaar)
{
this.tmpVar=tmpVar;
}

Note the typo in the method signature. This way, this.tmpVar=tmpVar is a
selfassignment.
Click to expand...

Indeed. It would be good to have it as at least a warning. Indeed, I
can't think of anywhere where it's *useful* - I'm just saying it's not
guaranteed to be a no-op.
 
a selfassignment is,if it is not a property always a no-op.
No it's not.

a = a;

could change the value of a, if there are multiple threads running:

Thread 1: Thread 2:
Read value of a
Assign different value to a
Write previously written
value back to a

If thread 1 omits its steps, the result is different.
Click to expand...


an unsynchronized read and write of variables between different threads
produces always undefined results.
sure the value of a can change with the assignment but what would be the
gain here? Nobody would seriously be so stupid and do such a thing, so that
is no point.

selfassignment of a variable should always produce a warning, I would even
go so far and say that it should be an compilererror.
 
codymanix said:
an unsynchronized read and write of variables between different threads
produces always undefined results.
sure the value of a can change with the assignment but what would be the
gain here? Nobody would seriously be so stupid and do such a thing, so that
is no point.
Click to expand...

I believe that's exactly what I said. I was merely taking issue with
your claim that "a=a" is always a no-op.
selfassignment of a variable should always produce a warning, I would even
go so far and say that it should be an compilererror.
Click to expand...

As I said, a warning would be good. I certainly wouldn't mind it being
an error. Personally I always get rid of all warnings anyway, so
effectively warnings and errors are the same for me.
 
Provide me one example where calling the same method/property without
impossible.

Without condition, that's true. And I dare say the compiler could pick
up on the simplest cases:

get
{
return PropertyName;
}
set
{
PropertyName = value;
}

But there are any number of cases which are "quite similar" and which
are obviously going to overflow but which the compiler would have a
hard time picking up. I can see the argument that if it's not going to
do a pretty thorough job, it shouldn't try to do the job at all.
Click to expand...


I would say that if the call to itself is the first method call in the
method the compile should issue an error,
since in this case executing the method would *always* produce a stack
overflow.

Consider the following:

Foo()
{
SomeMethod();
Foo();
}

Somemethod() could throw an exception which might be part of the application
logic that stops the recursion.

But if the call to itself is in a condional statement (loop/if), or a return
or throw or method/property invocation
precedes the recursive call I would only issue a warning.
 
cody said:
I would say that if the call to itself is the first method call in the
method the compile should issue an error,
since in this case executing the method would *always* produce a stack
overflow.
Click to expand...

Yes, that's possible. I don't know whether the compiler has that kind
of information easily available, but I suppose it's possible...

But if the call to itself is in a condional statement (loop/if), or a return
or throw or method/property invocation
precedes the recursive call I would only issue a warning.
Click to expand...

I would prefer no warning at all in that situation - it may well be
exactly the correct code, and reasonable code should never produce
warnings unless there's some easy (and readable) way of telling the
compiler that that really *is* what you mean.
 
But if the call to itself is in a condional statement (loop/if), or a
return
I would prefer no warning at all in that situation - it may well be
exactly the correct code, and reasonable code should never produce
warnings unless there's some easy (and readable) way of telling the
compiler that that really *is* what you mean.
Click to expand...


void Foo(int a, int b)
{
a/=b--;
Foo(a, b);
}

Would you consider this as reasonable and correct code that should not
produce a warning?
Note how the recursion is stopped by a DevisionByZeroException.

You can always use a #pragma warn to shut the compiler up in such
situatations. to stupid that c# doesn't yet support this nice feature.
 
codymanix said:
void Foo(int a, int b)
{
a/=b--;
Foo(a, b);
}

Would you consider this as reasonable and correct code that should not
produce a warning?
Click to expand...

I don't think it should produce a warning, really. I wouldn't say it's
particularly reasonable code, but I think it's sufficiently difficult
for the compiler to distinguish this from other, more reasonable code
that describing the rules could become more hassle than it's worth.
Note how the recursion is stopped by a DevisionByZeroException.
Click to expand...

That's not all you described, however. You talked about conditional
statements. Consider the classic example of recursion:

int Fibonacci (int number)
{
if (number < 2)
{
return 1;
}
return Fibonacci (number-1) + Fibonacci (number-2);
}

Ignore the fact that this particular instance (and many other users of
recursion) can be avoided using iteration - it's an example of the kind
of thing recursion is often used for. According to you, that should
produce a warning. I disagree.
You can always use a #pragma warn to shut the compiler up in such
situatations. to stupid that c# doesn't yet support this nice feature.
Click to expand...

No, I don't want to tell the compiler to stop emitting that warning
entirely though - I just want to *always* be able to describe
reasonable code in a way that doesn't cause the compiler to warn me in
the first place.
 
Back
Top