Properties Question

[dejas9000]

Why is:

internal Object Statement { private set; get; }

allowable but not:

Object Statement { private set; internal get; }

would they not have identical meaning?

 

[Alun Harford]

Why is:

internal Object Statement { private set; get; }

This is declaring an internal property with a private setter and
internal getter.

allowable but not:

Object Statement { private set; internal get; }

This is declaring a private property with a private setter and internal
getter - verboten.

Alun Harford

 

[Jon Skeet [C# MVP]]

Why is:

internal Object Statement { private set; get; }

allowable but not:

Object Statement { private set; internal get; }

would they not have identical meaning?

You've effectively declared *three* access levels for the last one - a
private "general access", then a private set and an internal get. You
can only specify the individual level for *either* the get *or* the
set, with the other getting the access level of the overall property.

 

[Jon Skeet [C# MVP]]

This is declaring a private property with a private setter and internal
getter - verboten.

And it's forbidden for two reasons in this case:

1) You can only add a setter/getter access modifier which is more
private than the "general" property

2) You can't have both accessors specified

 

[dejas9000]

So how is this requirement expressed?

1.) The property should have a public get and a public set.
2.) The property should not be inherited to child classes.

It seems this is not possible in C# yet would be potentially
desirable.

 

[Jon Skeet [C# MVP]]

So how is this requirement expressed?

1.) The property should have a public get and a public set.
2.) The property should not be inherited to child classes.

It seems this is not possible in C# yet would be potentially
desirable.

What do you mean by "the property should not be inherited"? Do you mean
you should be able to do:

Animal x = new Animal();
Console.WriteLine (x.Name);

but not

Giraffe g = new Giraffe();
Console.WriteLine (g.Name);

? If so, there's no way of doing so in C# and indeed there shouldn't be
- it would break Liskov's Substitutability Principle. Basically you
should always be able to use an instance of a derived type as an
instance of the base type.

 

[dejas9000]

Your interpretation is correct--however I argue that the
"Substitutability Principle" would remain intact because both the
public accessor and public specifier would be inherited via their
public declarations. In essence, I am looking for the property form
of:

class Animal { private String name;
public String getName() { ... }
public void setName(String newName) { ... }
}

class Giraffe : Animal
{
}

In your example above would not "g.Name" compile because (even though
the property was private) the compiler generated "getName()" would in
fact be public?

 

[Peter Duniho]

Your interpretation is correct--however I argue that the
"Substitutability Principle" would remain intact because both the
public accessor and public specifier would be inherited via their
public declarations.

Huh? You previously wrote you didn't want the property to be inherited.
Now you're saying that it would be? How does that work?

You seem to be confusing access modifiers (which only affect what code is
allowed to see members of a class) with inheritance (which isn't affected
by access modifiers).

Even private members are inherited. They can't be seen by inheriting
classes, but they still exist and they are visible to the declaring class,
even when the code in that declaring class is executing on an instance of
an inherited class. You can't stop base class members from being
inherited; it's a basic violation of OOP rules.

In essence, I am looking for the property form
of:

class Animal { private String name;
public String getName() { ... }
public void setName(String newName) { ... }
}

class Giraffe : Animal
{
}

There's no property in that example. There's a field, that's private.
And there's two public methods that (apparently) allow you to get and set
the field.

In your example above would not "g.Name" compile because (even though
the property was private) the compiler generated "getName()" would in
fact be public?

You most certainly could not write "g.Name" using your example and have it
successfully compile. A property is more than just a couple of
specially-named methods. Writing "getName()" and "setName()" methods does
not allow you to then use "Name" by itself as a property.

In any case, in what way is your example functionally different from:

class Animal
{
private String name;

public String Name
{
get { return name; }
set { name = value; }
}
}

In the above, a very conventional property declaration, the field where
the data is stored is still private, but the property and both accessors
are themselves public. How is that different from what you want to do?
What are you really trying to do here?

Pete

 

[Jon Skeet [C# MVP]]

Your interpretation is correct--however I argue that the
"Substitutability Principle" would remain intact because both the
public accessor and public specifier would be inherited via their
public declarations. In essence, I am looking for the property form
of:

class Animal { private String name;
public String getName() { ... }
public void setName(String newName) { ... }
}

class Giraffe : Animal
{
}

In your example above would not "g.Name" compile because (even though
the property was private) the compiler generated "getName()" would in
fact be public?

That's exactly what you get with:

class Animal
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Changing the access of the property does *nothing* to any variables the
property might access. Declaring a property doesn't automatically
declare a variable unless you're using C# 3's automatically implemented
properties, and in that case the variable is anonymous and always
private.