Prev: ChangeWindowMessageFilter und LateBinding
Next: After EndAccept new Socket has no LocalEndpoit-Compact Framewo
From: Geri Broser on 25 Oct 2009 07:52
Jeroen Mostert wrote:
> Geri Broser wrote:
> <snip>
>> I do not see any "delegate's [=method's] fields and methods" there.
>>
> Then your Intellisense is broken. :-)

Fortunately it's not. With "I do not see" I meant "in my mind", not "in my IDE". :-)

Geri
From: Peter Duniho on 25 Oct 2009 13:22
Geri Broser wrote:
> [...]
> Prevent replacing to make it foolproof is clear. I found that already
> when I tried...
>
> concert.CancellationHandler *=* evan.ReceiveE_Mail;
>
> ....with the event field version. (Which leads to "Compiler Error
> CS0070", for those who are interested.) However, I didn't consider this
> as remarkable, since fools should not program anyway. (OK, that's the
> theory... ;-)

All due respect, you are minimizing what is probably the most important
aspect of an event: the encapsulation hiding the implementation detail
from the client code. This is, in fact, one of the most important
aspect of pretty much all the OOP features in an OOP language (the other
most important being, of course, the ability to associate a data type
with specific behaviors).

First, whether they should or not, fools program all the time.

Second, even those who are not fools can be helped by language features
that enforce specific programming paradigms. If nothing else, it makes
explicit a contract that should already be implicit. It also protects
the non-fool implementor from the fool author of the client code.

The fact is, if you _can_ do something in code, sure as anything someone
will write code to do that, whether it's advised or not.

If your argument against this feature of events is that it only enforces
something everyone ought to know not to do anyway, then we can just get
rid of C# altogether, and C++ too. After all, OOP is mainly about
codifying abstract relationships between data and code. There's nothing
one can do in C#, C++, etc. that can't be done in C simply by having a
clear conventions document and expecting everyone to follow it.

If you find this feature of events in C# unremarkable, then you are
using the wrong programming language.

> Recognizing in designers and Intellisense is comprehensible, too.
>
> But, what do you mean by "gives them access to all the delegate's fields
> and methods"? A delegate is a function pointer, i.e. it represents a
> method. I do not see any "delegate's [=method's] fields and methods" there.

Using your subsequent reply to Jeroen as a guide, I have no idea what
you mean here. What you see "in your mind" is irrelevant. Even if by
some miracle, you are unable to perceive things in the code that are
really there, that has nothing at all to do with the question of whether
the language design is appropriate or useful.

Pete
From: Peter Duniho on 25 Oct 2009 13:25
Geri Broser wrote:
> [...]
> I had to think about, and try in code, what you meant by "gives them
> access to all the delegate's fields and methods". I thought a delegate
> is a function pointer, i.e. it represents a method, so there are no
> "delegate's [=method's] fields and methods". But then it became obvious
> that a delegate is the content of a variable of a delegate type - which
> is a reference type. So, it inherits Equals(), ToString(), ... from
> "Object" and more from others.

It does a lot more than that.
http://msdn.microsoft.com/en-us/library/system.multicastdelegate.aspx

But even if it didn't, the ability to simply hide the value of the
function pointer from client code is an important and useful feature.

Pete
From: Geri Broser on 25 Oct 2009 13:56
Peter Duniho schrieb:
> Geri Broser wrote:
>> [...]
>> Prevent replacing to make it foolproof is clear. I found that already
>> when I tried...
>>
>> concert.CancellationHandler *=* evan.ReceiveE_Mail;
>>
>> ....with the event field version. (Which leads to "Compiler Error
>> CS0070", for those who are interested.) However, I didn't consider
>> this as remarkable, since fools should not program anyway. (OK, that's
>> the theory... ;-)
>
> All due respect, you are minimizing what is probably the most important
> aspect of an event: the encapsulation hiding the implementation detail
> from the client code. This is, in fact, one of the most important
> aspect of pretty much all the OOP features in an OOP language (the other
> most important being, of course, the ability to associate a data type
> with specific behaviors).
>
> First, whether they should or not, fools program all the time.
>
> Second, even those who are not fools can be helped by language features
> that enforce specific programming paradigms. If nothing else, it makes
> explicit a contract that should already be implicit. It also protects
> the non-fool implementor from the fool author of the client code.
>
> The fact is, if you _can_ do something in code, sure as anything someone
> will write code to do that, whether it's advised or not.
>
> If your argument against this feature of events is that it only enforces
> something everyone ought to know not to do anyway, then we can just get
> rid of C# altogether, and C++ too. After all, OOP is mainly about
> codifying abstract relationships between data and code. There's nothing
> one can do in C#, C++, etc. that can't be done in C simply by having a
> clear conventions document and expecting everyone to follow it.
>
> If you find this feature of events in C# unremarkable, then you are
> using the wrong programming language.
>
>> Recognizing in designers and Intellisense is comprehensible, too.
>>
>> But, what do you mean by "gives them access to all the delegate's
>> fields and methods"? A delegate is a function pointer, i.e. it
>> represents a method. I do not see any "delegate's [=method's] fields
>> and methods" there.
>
> Using your subsequent reply to Jeroen as a guide, I have no idea what
> you mean here. What you see "in your mind" is irrelevant. Even if by
> some miracle, you are unable to perceive things in the code that are
> really there, that has nothing at all to do with the question of whether
> the language design is appropriate or useful.
>
> Pete

Thank you, Pete, for construeing so much. Thank you for taking things too serious. Thank you for being against my
arguments agianst while I wasn't arguing at all. Thank you for telling me I'm an idiot using the wrong language. Thank
you for confirming the fact that written words often cannot convey the writer's intention. Thank you for ignoring that
I'm not a native English speaker, so this can happen a lot easier. Thank you for showing me that I'm not the only nerd
in this world. Thank you for telling me all that at my first day here.

Thank you
Geri
From: Peter Duniho on 25 Oct 2009 15:24
Geri Broser wrote:
> Thank you, Pete, for construeing so much. Thank you for taking things
> too serious. Thank you for being against my arguments agianst while I
> wasn't arguing at all. Thank you for telling me I'm an idiot using the
> wrong language. Thank you for confirming the fact that written words
> often cannot convey the writer's intention. Thank you for ignoring that
> I'm not a native English speaker, so this can happen a lot easier. Thank
> you for showing me that I'm not the only nerd in this world. Thank you
> for telling me all that at my first day here.

You're welcome. Always happy to help out.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ChangeWindowMessageFilter und LateBinding
Next: After EndAccept new Socket has no LocalEndpoit-Compact Framewo