Re: Double posts

I see the twice


Greg Robinson
Custom Data Systems, Inc.
www.cds-am.net

-----Original Message-----
From: Discussion of development on the .NET platform using any managed
language [mailto:[email protected]]On Behalf Of Dean
Cleaver
Sent: Wednesday, November 21, 2007 2:35 AM
To: [email protected]
Subject: Re: [DOTNET-CLR] Double posts


None here...

-----Original Message-----
From: Discussion of development on the .NET platform using any managed
language [mailto:[email protected]] On Behalf Of Richard
Blewett
Sent: Wednesday, 21 November 2007 20:10
To: [email protected]
Subject: [DOTNET-CLR] Double posts

Is anyone else seeing all the messages twice or do I have some Outlook
rule
madness going on?

Regards

Richard Blewett - DevelopMentor

> -----Original Message-----
> From: Discussion of development on the .NET platform using any managed
> language [mailto:[email protected]] On Behalf Of Richard
> Blewett
> Sent: 21 November 2007 00:27
> To: [email protected]
> Subject: Re: [DOTNET-CLR] FW: C# 3.0 Automatic Properties
>
> <Inline>
>
> Regards
>
> Richard Blewett - DevelopMentor
>
> > -----Original Message-----
> > From: Discussion of development on the .NET platform using any
> managed
> > language [mailto:[email protected]] On Behalf Of Keith
> > Hill
> > Sent: 20 November 2007 21:54
> > To: [email protected]
> > Subject: [DOTNET-CLR] FW: C# 3.0 Automatic Properties
> >
> > > -----Original Message-----
> > > From: Fabian Schmied [mailto:[email protected]]
> > > Sent: Wednesday, November 14, 2007 1:22 AM
> > > Subject: Re: C# 3.0 Automatic Properties
> > > Encapsulation is a nice word, but IMO in many, many cases (like
> > > utility structs) public readonly fields do the job very well. I've
> > yet
> > > to hear a convincing reason to prefer properties over public
> readonly
> > > fields when both of them would be applicable.
> >
> > I have to disagree.  IMO it is a bad idea to expose public fields
> (even
> > readonly) unless you are talking about a true cosmological constant
> > like Pi or E.  The reason is that public field values get baked
> > (compiled) into your client's code.  Once a client has compiled
> against
> > your type, it will never ask for that public field value again until
> > you recompile.  So if you decide to change the value well then all
> your
> > clients will have to recompile.
>
> Hmmm - this is not true. Constant values are baked into the consumer
> but
> fields are not - so this objection is not valid. I agree with the rest
> of
> your objections
>
> And as far as performance is concerned
> > most trivial property getters are inlined.  Furthermore, you may
> decide
> > that you need logic in the retrieval of the field's value - oops
> can't
> > do that.  Non-readonly fields are worse since they can never be
> thread
> > safe (unless there is a field sync attribute I don't know about).
> >
> > BTW for the folks objecting to the compiler syntactic sugar known as
> > automatic properties, how is this that different than what the
> compiler
> > does for you when you use the event keyword?
> >
> > --
> > Keith
> >
> > ===================================
> > This list is hosted by DevelopMentor.  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor.  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor.  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com