473,322 Members | 1,714 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

c# 2.x feature requests

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
Nov 17 '05 #1
19 1127
steve <st***@discussions.microsoft.com> 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #2
Thanks for the feedback.

"Jon Skeet [C# MVP]" wrote:
steve <st***@discussions.microsoft.com> 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #3

"steve" <st***@discussions.microsoft.com> wrote in message
news:0D**********************************@microsof t.com...
Thanks for the feedback.

"Jon Skeet [C# MVP]" wrote:
steve <st***@discussions.microsoft.com> 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
Nov 17 '05 #4
Hello Michael,
"steve" <st***@discussions.microsoft.com> wrote in message
news:0D**********************************@microsof t.com...
Thanks for the feedback.

"Jon Skeet [C# MVP]" wrote:
steve <st***@discussions.microsoft.com> 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/
mailto:la***@vkarlsen.no
PGP KeyID: 0x0270466B
Nov 17 '05 #5
I know this.
But I like how it works in Delphi much better.

- Michael S

"Lasse Våqsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:9d**************************@news.microsoft.c om...
Hello Michael,
"steve" <st***@discussions.microsoft.com> wrote in message
news:0D**********************************@microsof t.com...
Thanks for the feedback.

"Jon Skeet [C# MVP]" wrote:

steve <st***@discussions.microsoft.com> 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/
mailto:la***@vkarlsen.no
PGP KeyID: 0x0270466B

Nov 17 '05 #6
steve <st***@discussions.microsoft.com> 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #7
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

Nov 17 '05 #8
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

Nov 17 '05 #9
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #10
Brian Gideon <br*********@yahoo.com> wrote:
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.


It's in the C# spec (the ECMA version) in section 17.7.1:

<quote>
When compiling a field-like event, the compiler automatically creates
storage to hold the delegate, and creates accessors for the event that
add or remove event handlers to the delegate field. 2 In order to be
thread-safe, the addition or removal operations are done while holding
the lock (§15.12) on the containing object for an instance event, or
the type object (§14.5.11) for a static event.
</quote>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #11
Jon wrote:
Brian Gideon <br*********@yahoo.com> wrote:
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.


It's in the C# spec (the ECMA version) in section 17.7.1:

<quote>
When compiling a field-like event, the compiler automatically creates
storage to hold the delegate, and creates accessors for the event that
add or remove event handlers to the delegate field. 2 In order to be
thread-safe, the addition or removal operations are done while holding
the lock (§15.12) on the containing object for an instance event, or
the type object (§14.5.11) for a static event.
</quote>


Ah...thanks. I knew it had to be somewhere.

Nov 17 '05 #12
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?

I just wanted to add that the solution to the race condition presented
in that article still isn't safe according to

http://blogs.msdn.com/grantri/archiv...07/226355.aspx

The delegate field must be volatile (which it isn't in the code
generated by the simple event syntax), or you can follow Jon's example
and place a lock around it.
See http://www.pobox.com/~skeet/csharp/lockchoice.shtml


/threads/lockchoice.shtml

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 17 '05 #13
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

Hee he. Wise you are master grasshopper. Hadn't thought of synchronised
context switches.. will add the little mods you highlighted in the
lockchoice page. Cheers.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #14
How about this Jon? Have a look at the OnSomethingHappened method.

#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()
{
// New Code thanks to Jon Skeet
//

SomethingHappenedEvent SomethingHappened;
lock (SomethingHappenedEventLock)
{
SomethingHappened = mSomethingHappened;
}

// Correct me if i'm wrong here, but...
//
// If we get a context switch here and a thread
// detaches a handler from the SomethingHappened event
// the handler will still *receive* one last event..

if SomethingHappened != null)
{
SomethingHappened(this, new SomethingHappenedEventArgs());
}

// Old Code
//
// This can deadlock if the =- or += overloads are called by a
// synchronised thread indirection, eg. Control.Invoke

// lock (SomethingHappenedEventLock)
// {
// if (mSomethingHappened != null)
// {
// mSomethingHappened(this, new SomethingHappenedEventArgs());
// }
}
}

#endregion

Nov 17 '05 #15
steve <st***@discussions.microsoft.com> wrote:
How about this Jon? Have a look at the OnSomethingHappened method.


Well, it's still not clear to me why you've got all the resource
acquisition stuff there - after all, if you don't need the resources
until an event occurs, that's when you should acquire them, and you
should release them immediately afterwards.

You're right that there's still a race condition - but if you consider
the unsubscription (or extra subscription) to occur at "the same time"
as raising the event, then it's just as correct to process the
subscription differences after the event as before it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #16
Thanks again Jon

The resource allocation / deallocation areas are just me brainstorming. It
may make sense to only allocate resources when there is an eventhandler
plumbed into the system. In other words is there any point consuming these
resources when there are no event handlers for the event.

For instance say the *thing* that sources the event comes through interop.
Furthermore say that this interop thing consumes a shared physical resource,
eg. RS-232 port. It may not make sense for this resource to be consumed when
there are no event handlers plumbed into the event... Hence the resource
allocation / deallocation.

Thoughts?

Ciao

Steve

"Jon Skeet [C# MVP]" wrote:
steve <st***@discussions.microsoft.com> wrote:
How about this Jon? Have a look at the OnSomethingHappened method.


Well, it's still not clear to me why you've got all the resource
acquisition stuff there - after all, if you don't need the resources
until an event occurs, that's when you should acquire them, and you
should release them immediately afterwards.

You're right that there's still a race condition - but if you consider
the unsubscription (or extra subscription) to occur at "the same time"
as raising the event, then it's just as correct to process the
subscription differences after the event as before it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #17
Here's another one

constant arrays, ie.

const byte[] E2PROM_DATA_DEF = {0x01, 0x02, 0x03, 0x04, ...};

"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

Nov 17 '05 #18
steve <st***@discussions.microsoft.com> wrote:
Thanks again Jon

The resource allocation / deallocation areas are just me brainstorming. It
may make sense to only allocate resources when there is an eventhandler
plumbed into the system. In other words is there any point consuming these
resources when there are no event handlers for the event.

For instance say the *thing* that sources the event comes through interop.
Furthermore say that this interop thing consumes a shared physical resource,
eg. RS-232 port. It may not make sense for this resource to be consumed when
there are no event handlers plumbed into the event... Hence the resource
allocation / deallocation.

Thoughts?


Yes, that sounds fairly reasonable. It's not something I've ever had to
do, and I'd suggest that it should be the exception rather than the
rule, but it could be handy sometimes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #19
use can use "static readonly" instead :)
"steve" <st***@discussions.microsoft.com> schrieb im Newsbeitrag
news:A1**********************************@microsof t.com...
Here's another one

constant arrays, ie.

const byte[] E2PROM_DATA_DEF = {0x01, 0x02, 0x03, 0x04, ...};

"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

Nov 17 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

48
by: Zenobia | last post by:
Recently I was editing a document in GoLive 6. I like GoLive because it has some nice features such as: * rewrite source code * check syntax * global search & replace (through several files at...
25
by: | last post by:
Hi, The following code shows the FolderBrowserDialog = broken. FolderBrowserDialog folderDialog = new FolderBrowserDialog(); folderDialog.ShowNewFolderButton = false;...
14
by: Tom.PesterDELETETHISSS | last post by:
Hi, I think this question requires an in depth understanding of how a browser cache works. I hope I can reach an expert here. I may have found a quirk in the asp.net documentation or I don't...
30
by: Raymond Hettinger | last post by:
Proposal -------- I am gathering data to evaluate a request for an alternate version of itertools.izip() with a None fill-in feature like that for the built-in map() function: >>> map(None,...
12
by: Raymond Hettinger | last post by:
I am evaluating a request for an alternate version of itertools.izip() that has a None fill-in feature like the built-in map function: >>> map(None, 'abc', '12345') # demonstrate map's None...
32
by: toolmaster | last post by:
Since many of the modern computer languages have built-in namespace features, I can't understand why not add this feature into standard C. I've heard many people complain of the lacking of...
19
by: George Sakkis | last post by:
It would be useful if list.sort() accepted two more optional parameters, start and stop, so that you can sort a slice in place. In other words, x = range(1000000) x.sort(start=3, stop=-1) ...
2
by: loulou384 | last post by:
The Many Layers of Ajax by Justin Gehtland The term "Ajax" was born on February 18, 2005, in a white paper called "Ajax: A New Approach to Web Applications" by Jesse James Garrett of Adaptive...
1
by: Brennan Stehling | last post by:
I have posted 4 feature requests here... https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=232161 Please vote for them if you think they would be useful. I...
10
by: Conrad Lender | last post by:
In a recent thread in this group, I said that in some cases object detection and feature tests weren't sufficient in the development of cross-browser applications, and that there were situations...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.