Don't know if this is the correct forum for this, but here goes..

- independent access level modifiers for property get and set members
eg. public get, protected set, set provides validation / thread sync
facilities
- default class member access set to protected rather than private
- automagic thread concurrency managment for the add / remove event members
eg. automagic management of thread concurrency issues associated with +=
and -= event overloads

...

anyone else care to comment

-- Steve

steve <(E-Mail Removed)> wrote:
> Don't know if this is the correct forum for this, but here goes..
>
> - independent access level modifiers for property get and set members
> eg. public get, protected set, set provides validation / thread sync
> facilities

That's already in the beta.

> - default class member access set to protected rather than private

Thankfully that's *not* in the beta. Protected access should be used
more rarely than private access (particularly for fields). In addition,
if you make something private but it should actually be protected,
you're likely to find out at compile time. The other way round, you'll
never know until something uses the unintended access...

> - automagic thread concurrency managment for the add / remove event members
> eg. automagic management of thread concurrency issues associated with +=
> and -= event overloads

What exactly would you want it to do? Currently it locks on "this" and
I believe it will at least be *allowed* to lock on a private member
variable instead if the compiler decides to.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Thanks for the feedback.

"Jon Skeet [C# MVP]" wrote:

> steve <(E-Mail Removed)> wrote:
> > Don't know if this is the correct forum for this, but here goes..
> >
> > - independent access level modifiers for property get and set members
> > eg. public get, protected set, set provides validation / thread sync
> > facilities
>
> That's already in the beta.
>

good

> > - default class member access set to protected rather than private
>
> Thankfully that's *not* in the beta. Protected access should be used
> more rarely than private access (particularly for fields). In addition,
> if you make something private but it should actually be protected,
> you're likely to find out at compile time. The other way round, you'll
> never know until something uses the unintended access...
>

fair enough for fields. But invariably I find that I want to call methods
of ancestors. Yes I agree that it is best to encapsulate as much as
possible, I guess it's just a bit harder when your in a hurry.. ; )

> > - automagic thread concurrency managment for the add / remove event members
> > eg. automagic management of thread concurrency issues associated with +=
> > and -= event overloads
>
> What exactly would you want it to do? Currently it locks on "this" and
> I believe it will at least be *allowed* to lock on a private member
> variable instead if the compiler decides to.
>

I googled up this commentary on event race conditions

http://blogs.msdn.com/csharpfaq/arch.../19/93082.aspx

This is what I have been doing to avoid probs when wiring / unwiring
delegates. comments?

#region SomethingHappenedEvent

object SomethingHappenedEventLock = new object();
protected event SomethingHappenedEvent mSomethingHappened;
public event SomethingHappenedEvent SomethingHappened
{
add
{
lock (SomethingHappenedEventLock)
{
if (mSomethingHappened == null)
{
// Acquire any shared resources required for processing event
}
mSomethingHappened += value;
}
}
remove
{
lock (SomethingHappenedEventLock)
{
mSomethingHappened -= value;
if (mSomethingHappened == null)
{
// Release any shared resources required for processing event
}
}
}
}

protected virtual void OnSomethingHappened()
{
lock (SomethingHappenedEventLock)
{
if (mSomethingHappened != null)
{
mSomethingHappened(this, new SomethingHappenedEventArgs());
}
}
}

#endregion


> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
>

"steve" <(E-Mail Removed)> wrote in message
news:0D33EAFA-654B-490B-BE78-(E-Mail Removed)...
> Thanks for the feedback.
>
> "Jon Skeet [C# MVP]" wrote:
>
>> steve <(E-Mail Removed)> wrote:
>> > Don't know if this is the correct forum for this, but here goes..
>> >
>> > - independent access level modifiers for property get and set members
>> > eg. public get, protected set, set provides validation / thread sync
>> > facilities
>>
>> That's already in the beta.
>>
>
> good

Yes, it's great. However I'll always miss the friend modifier in C++ or as
done in Delphi.

>
>> > - default class member access set to protected rather than private
>>
>> Thankfully that's *not* in the beta. Protected access should be used
>> more rarely than private access (particularly for fields). In addition,
>> if you make something private but it should actually be protected,
>> you're likely to find out at compile time. The other way round, you'll
>> never know until something uses the unintended access...
>>
>
> fair enough for fields. But invariably I find that I want to call methods
> of ancestors. Yes I agree that it is best to encapsulate as much as
> possible, I guess it's just a bit harder when your in a hurry.. ; )

Hehe, I've never been in such a hurry. Also, I would avoid coding virtual
classes when in panic. =)

Happy Coding
- Michael S

Hello Michael,

> "steve" <(E-Mail Removed)> wrote in message
> news:0D33EAFA-654B-490B-BE78-(E-Mail Removed)...
>
>> Thanks for the feedback.
>>
>> "Jon Skeet [C# MVP]" wrote:
>>
>>> steve <(E-Mail Removed)> wrote:
>>>
>>>> Don't know if this is the correct forum for this, but here goes..
>>>>
>>>> - independent access level modifiers for property get and set
>>>> members eg. public get, protected set, set provides validation /
>>>> thread sync facilities
>>>>
>>> That's already in the beta.
>>>
>> good
>>
> Yes, it's great. However I'll always miss the friend modifier in C++
> or as done in Delphi.

"friend" is available through internal methods, which will thus be available
throughout your entire assembly. I know, this allows all the code in that
assembly to reach those methods, but they will at least be available to you,
and not to any code outside of the assembly.

--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
private.php?do=newpm&u=
PGP KeyID: 0x0270466

I know this.
But I like how it works in Delphi much better.

- Michael S

"Lasse Våqsæther Karlsen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello Michael,
>
>> "steve" <(E-Mail Removed)> wrote in message
>> news:0D33EAFA-654B-490B-BE78-(E-Mail Removed)...
>>
>>> Thanks for the feedback.
>>>
>>> "Jon Skeet [C# MVP]" wrote:
>>>
>>>> steve <(E-Mail Removed)> wrote:
>>>>
>>>>> Don't know if this is the correct forum for this, but here goes..
>>>>>
>>>>> - independent access level modifiers for property get and set
>>>>> members eg. public get, protected set, set provides validation /
>>>>> thread sync facilities
>>>>>
>>>> That's already in the beta.
>>>>
>>> good
>>>
>> Yes, it's great. However I'll always miss the friend modifier in C++
>> or as done in Delphi.
>
> "friend" is available through internal methods, which will thus be
> available throughout your entire assembly. I know, this allows all the
> code in that assembly to reach those methods, but they will at least be
> available to you, and not to any code outside of the assembly.
>
> --
> Lasse Vågsæther Karlsen
> http://www.vkarlsen.no/
> private.php?do=newpm&u=
> PGP KeyID: 0x0270466B
>
>

steve <(E-Mail Removed)> wrote:
> > > - default class member access set to protected rather than private
> >
> > Thankfully that's *not* in the beta. Protected access should be used
> > more rarely than private access (particularly for fields). In addition,
> > if you make something private but it should actually be protected,
> > you're likely to find out at compile time. The other way round, you'll
> > never know until something uses the unintended access...
>
> fair enough for fields. But invariably I find that I want to call methods
> of ancestors. Yes I agree that it is best to encapsulate as much as
> possible, I guess it's just a bit harder when your in a hurry.. ; )

I think it would be a really bad idea for a language change to
encourage rushed programming.

Personally, I don't used protected methods very often - but then I
favour composition over inheritance in the first place.

> > What exactly would you want it to do? Currently it locks on "this" and
> > I believe it will at least be *allowed* to lock on a private member
> > variable instead if the compiler decides to.
>
> I googled up this commentary on event race conditions
>
> http://blogs.msdn.com/csharpfaq/arch.../19/93082.aspx
>
> This is what I have been doing to avoid probs when wiring / unwiring
> delegates. comments?

Sure - it's broken in a different way. You're maintaining the lock for
the whole of the time the event is running. Given that events in UIs
often involve Control.Invoke, you could easily end up with a deadlock.

See http://www.pobox.com/~skeet/csharp/lockchoice.shtml


--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Great ideas, Steve. Keep them coming!

Private data is a misnomer... I haven't tried it in C#, but in C++ you'd
have no problem breaking into private data with a few casts and pointer
arithmetic. It helps if you have the class definition and an understanding of
the memory mapping.

So, I see the real reason for defaulting to private as that it promotes
encapsulation, making derived classes more proper, and your class free from
worrying about what those derived classes could be doing easily that they
shouldn't.

As for more automagic delegate support, I agree in general. I posted a
comment titled "C# Language Specification - Delegates", which deals with some
of the stuff.

I have problems with third-party components that generate exceptions which
they don't rethrow, and who attach to events but don't remove those event
handlers when they are disposed. Hence, it's not something I can easily
overcome unless it's made automagic.

"steve" wrote:

> Don't know if this is the correct forum for this, but here goes..
>
> - independent access level modifiers for property get and set members
> eg. public get, protected set, set provides validation / thread sync
> facilities
> - default class member access set to protected rather than private
> - automagic thread concurrency managment for the add / remove event members
> eg. automagic management of thread concurrency issues associated with +=
> and -= event overloads
>
> ..
>
> anyone else care to comment
>
> -- Steve

Jon wrote:
> > - automagic thread concurrency managment for the add / remove event members
> > eg. automagic management of thread concurrency issues associated with +=
> > and -= event overloads
>
> What exactly would you want it to do? Currently it locks on "this" and
> I believe it will at least be *allowed* to lock on a private member
> variable instead if the compiler decides to.
>

Jon, I've seen you mention this before and it's in your lock choice
article as well. I don't doubt that you are correct about that. That
is, that the compiler locks on "this" automatically if you do not
include the add/remove code for events. But, where did you learn about
this? I assumed that there wasn't any synchronization going on because
I didn't find any mention of it in the C# specification or other
documentation.

Brian

Marshal [DirectX MVP 2003] <MarshalDirectXMVP2003
@discussions.microsoft.com> wrote:
> Great ideas, Steve. Keep them coming!
>
> Private data is a misnomer... I haven't tried it in C#, but in C++ you'd
> have no problem breaking into private data with a few casts and pointer
> arithmetic. It helps if you have the class definition and an understanding of
> the memory mapping.

You can't do that in C#. You can break the privacy using reflection,
but only if you've got the appropriate permissions.

<snip>

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too