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 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
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
"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
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
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
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
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 - <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
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
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. 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
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
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
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
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
by: |
last post by:
Hi,
The following code shows the FolderBrowserDialog = broken.
FolderBrowserDialog folderDialog = new FolderBrowserDialog();
folderDialog.ShowNewFolderButton = false;...
|
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...
|
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,...
|
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...
|
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...
|
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)
...
|
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...
|
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...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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)...
|
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....
|
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
|
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...
| |