Re: Properties

[mike smith]

About the only time fields might be preferable is where you want to read a
file (a bitmap, say) and then cast it to a class. A lot of the lower-level
classes in MFC did that.  CRect, CPoint, etc.

On 25 August 2010 12:07, Mark Ryall  wrote:

> If you create some library that expose anemic DTO classes that have public
> and mutable fields and no behaviour then you'll have great difficulty ever
> taking that away.  That applies even if you're the only consumer.
>
> There are certainly some occasions where this is justifiable (for
> serialising objects or transfer or persistance or whatever - ORMs usually
> require these unfortunate sort of classes) but seems to mostly defeat the
> purpose of OO.
>
> I prefer languages (like ruby or smalltalk for instance) that don't give
> you the option of exposing the internal state of classes (without some
> degree of violence) unless you create methods (which is all properties
> really are).
>
> That's not because i'm a purist - there are just fewer things to worry
> about when your classes are mostly immutable except via behaviours you
> choose to add to them.
>
> On Wed, Aug 25, 2010 at 11:54 AM, Jeff Sinclair <
> jeff.sinclair.em...@gmail.com> wrote:
>
>> True, with properties, changes can be completed maintaining binary
>> compatibility.
>> But really how often do you have an assembly where binary compatibility is
>> actually an issue?
>> Sometime sure, but I'm thinking it's more often the exception than the
>> rule.
>>
>> Adding properties in later maintains source compatibility, and generally
>> I've found that's more than enough.
>>
>> Jeff
>>
>> -Original Message-
>> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com
>> ]
>> On Behalf Of Mark Hurd
>> Sent: Wednesday, 25 August 2010 9:28 AM
>> To: ozDotNet
>> Subject: Re: Properties
>>
>> The thing with properties is that once you have them, changes can be
>> completed without changing the interface, including the binary
>> compatibility
>> of public interfaces.
>>
>> Nevertheless, if your class of variables is not public I too would
>> consider
>> just using fields.
>> --
>> Regards,
>> Mark Hurd, B.Sc.(Ma.)(Hons.)
>>
>> On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
>>  wrote:
>> > Can some one tell me why people get so worked up about all fields
>> > being private and accessed only via properties.
>> >
>> > If you have a class which is only used essentially as group of
>> > variables, eg to put into a data structure like a tree or something
>> > then why not public fields?
>> >
>> > Do all those properties really add any value?
>> >
>> > Jeff
>>
>>
>


-- 
Meski

"Going to Starbucks for coffee is like going to prison for sex. Sure, you'll
get it, but it's going to be rough" - Adam Hills

Re: Properties

[Mark Ryall]

If you create some library that expose anemic DTO classes that have public
and mutable fields and no behaviour then you'll have great difficulty ever
taking that away.  That applies even if you're the only consumer.

There are certainly some occasions where this is justifiable (for
serialising objects or transfer or persistance or whatever - ORMs usually
require these unfortunate sort of classes) but seems to mostly defeat the
purpose of OO.

I prefer languages (like ruby or smalltalk for instance) that don't give you
the option of exposing the internal state of classes (without some degree of
violence) unless you create methods (which is all properties really are).

That's not because i'm a purist - there are just fewer things to worry about
when your classes are mostly immutable except via behaviours you choose to
add to them.

On Wed, Aug 25, 2010 at 11:54 AM, Jeff Sinclair <
jeff.sinclair.em...@gmail.com> wrote:

> True, with properties, changes can be completed maintaining binary
> compatibility.
> But really how often do you have an assembly where binary compatibility is
> actually an issue?
> Sometime sure, but I'm thinking it's more often the exception than the
> rule.
>
> Adding properties in later maintains source compatibility, and generally
> I've found that's more than enough.
>
> Jeff
>
> -Original Message-
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
> On Behalf Of Mark Hurd
> Sent: Wednesday, 25 August 2010 9:28 AM
> To: ozDotNet
> Subject: Re: Properties
>
> The thing with properties is that once you have them, changes can be
> completed without changing the interface, including the binary
> compatibility
> of public interfaces.
>
> Nevertheless, if your class of variables is not public I too would consider
> just using fields.
> --
> Regards,
> Mark Hurd, B.Sc.(Ma.)(Hons.)
>
> On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
>  wrote:
> > Can some one tell me why people get so worked up about all fields
> > being private and accessed only via properties.
> >
> > If you have a class which is only used essentially as group of
> > variables, eg to put into a data structure like a tree or something
> > then why not public fields?
> >
> > Do all those properties really add any value?
> >
> > Jeff
>
>

Re: Properties

[David Richards]

The OP wasn't asking if properties are more feature rich so no, I wont
back you up on this one :)

My opinion is, it depends.  There is nothign wrong with using public
fields if it makes sense.  If you have a private class that will never
change or changes are trivial to propagate then sure, use fields.  If
validation or any other any property feature will never be needed,
sure use fields.

If it's public, it's a bit different.  You are making a contract so
properties make it easier to keep that contract.  If you are abolutely
certain the requirements will never change, you probably still want
properties if only because that is what people expect and you dont
want to annoy people using your library.  If you still want to use
fields, you have to accept the potential inconvenience you are
creating for others.

David

"If we can hit that bullseye, the rest of the dominoes
 will fall like a house of cards... checkmate!"
 -Zapp Brannigan, Futurama


On Wed, Aug 25, 2010 at 11:39, Michael Lyons  wrote:
> Properties allow you to do more things with a variable, for instance a
> validation check or an update call back event, while fields do not.
> Properties should always be light weight though and not become a method.
>
>
>
> This also imposes on anyone who may use’s your software as compile time
> linking will be broken. It’s just much easier to make it a property to start
> with and then modify it later on than having a field and breaking who knows
> what. This is what we call a breaking change.
>
>
>
> You can’t databind on fields.
>
>
>
> By using properties you have more control to, so for instance let’s say you
> have a generic list and you expose that as a field, the whole object can be
> overwritten, compared to a property which you make the set a private instead
> of public which allows the list object to be read only but still completely
> useable.
>
>
>
> Also it’s just plain bad practice to do so as everyone should stick to some
> general platform coding guidelines.
>
>
>
> Anyone else wish to back me up on this one?
>

RE: Properties

[Jeff Sinclair]

True, with properties, changes can be completed maintaining binary
compatibility.
But really how often do you have an assembly where binary compatibility is
actually an issue? 
Sometime sure, but I'm thinking it's more often the exception than the rule.

Adding properties in later maintains source compatibility, and generally
I've found that's more than enough.

Jeff

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Mark Hurd
Sent: Wednesday, 25 August 2010 9:28 AM
To: ozDotNet
Subject: Re: Properties

The thing with properties is that once you have them, changes can be
completed without changing the interface, including the binary compatibility
of public interfaces.

Nevertheless, if your class of variables is not public I too would consider
just using fields.
--
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
 wrote:
> Can some one tell me why people get so worked up about all fields 
> being private and accessed only via properties.
>
> If you have a class which is only used essentially as group of 
> variables, eg to put into a data structure like a tree or something 
> then why not public fields?
>
> Do all those properties really add any value?
>
> Jeff

RE: Properties

[James Chapman-Smith]

Hi Jeff,

 

Here are a few things to consider.

 

. You can't ensure that the inner state (encapsulation) of your
objects is maintained using fields. An `Age` field might be set to `-1`, for
example.

. You can't implement `INotifyPropertyChanged` on a field - so
fields don't work with data binding.

. You can't implement any form of logging on field assignment. Same
is true for validation and security checks.

. You can't set debug break-points on a field.

. You can't use a field to implement an interface.

. You can't override fields in derived classes.

. You can expose a property as public for reading and
protected/internal/private for writing. You can't do that with a field - if
it's public to read then it is public to write.

. Exposing fields allows callers to your class to use your fields as
`ref` parameters in calls to any arbitrary method - `ref` parameters are bad
in my book in any case - and if this happens then you can't change the field
to a property later on as properties cannot be passed as `ref` parameters.

. Code to use reflection is different for accessing fields and
properties. If you only expose properties then you only have to worry about
one type of reflection.

. Standard naming conventions whereby fields use "underscore camel
case" vs properties using "pascal case" cannot be maintained when exposing
fields publicly.

 

I think that's all I can come up with off the top of my head.

 

And remember, declaring `public int Age;` versus `public int Age { get; set;
}` is only a trivial change.

 

I hope this helps.

 

Cheers.

 

James.

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Jeff Sinclair
Sent: Wednesday, 25 August 2010 10:43
To: 'ozDotNet'
Subject: Properties

 

Can some one tell me why people get so worked up about all fields being
private and accessed only via properties.

If you have a class which is only used essentially as group of variables, eg
to put into a data structure like a tree or something then why not public
fields? 

Do all those properties really add any value?

 

Jeff

 

 

RE: Properties

[Greg Keogh]

 Fields don't scale well. You can't decide to add validation or special
behaviour to them later. Proxy code generators usually ignore them. You
can't convert one into a dependency property later. They won't appear in the
PropertyGrid control. They have different serialization behaviour. You can't
put different access modifiers on the get/set of a field.

 

You can use abbreviated property { get; set; } syntax, so why not do that
instead of using fields, and you'll get the possible benefits later. I doubt
if there is any performance difference between fields and properties (unless
anyone has news that this is an argument for using fields).

 

Greg

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Jeff Sinclair
Sent: Wednesday, 25 August 2010 11:13
To: 'ozDotNet'
Subject: Properties

 

Can some one tell me why people get so worked up about all fields being
private and accessed only via properties.

If you have a class which is only used essentially as group of variables, eg
to put into a data structure like a tree or something then why not public
fields? 

Do all those properties really add any value?

 

Jeff

 

 

RE: Properties

[Michael Lyons]

Properties allow you to do more things with a variable, for instance a
validation check or an update call back event, while fields do not.
Properties should always be light weight though and not become a method.

 

This also imposes on anyone who may use's your software as compile time
linking will be broken. It's just much easier to make it a property to start
with and then modify it later on than having a field and breaking who knows
what. This is what we call a breaking change.

 

You can't databind on fields.

 

By using properties you have more control to, so for instance let's say you
have a generic list and you expose that as a field, the whole object can be
overwritten, compared to a property which you make the set a private instead
of public which allows the list object to be read only but still completely
useable.

 

Also it's just plain bad practice to do so as everyone should stick to some
general platform coding guidelines.

 

Anyone else wish to back me up on this one?

 



Michael Lyons

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Jeff Sinclair
Sent: Wednesday, 25 August 2010 11:13 AM
To: 'ozDotNet'
Subject: Properties

 

Can some one tell me why people get so worked up about all fields being
private and accessed only via properties.

If you have a class which is only used essentially as group of variables, eg
to put into a data structure like a tree or something then why not public
fields? 

Do all those properties really add any value?

 

Jeff

 

 

Re: Properties

[David Burstin]

One other thing to consider is that fields cannot be part of an interface,
so if you are doing TDD and need to mock a field it can't be done.

On Wed, Aug 25, 2010 at 11:28 AM, Mark Hurd  wrote:

> The thing with properties is that once you have them, changes can be
> completed without changing the interface, including the binary
> compatibility of public interfaces.
>
> Nevertheless, if your class of variables is not public I too would
> consider just using fields.
> --
> Regards,
> Mark Hurd, B.Sc.(Ma.)(Hons.)
>
> On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
>  wrote:
> > Can some one tell me why people get so worked up about all fields being
> > private and accessed only via properties.
> >
> > If you have a class which is only used essentially as group of variables,
> eg
> > to put into a data structure like a tree or something then why not public
> > fields?
> >
> > Do all those properties really add any value?
> >
> > Jeff
>

Re: Properties

[Mark Hurd]

The thing with properties is that once you have them, changes can be
completed without changing the interface, including the binary
compatibility of public interfaces.

Nevertheless, if your class of variables is not public I too would
consider just using fields.
-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
 wrote:
> Can some one tell me why people get so worked up about all fields being
> private and accessed only via properties.
>
> If you have a class which is only used essentially as group of variables, eg
> to put into a data structure like a tree or something then why not public
> fields?
>
> Do all those properties really add any value?
>
> Jeff

Properties

[Jeff Sinclair]

Can some one tell me why people get so worked up about all fields being
private and accessed only via properties.

If you have a class which is only used essentially as group of variables, eg
to put into a data structure like a tree or something then why not public
fields? 

Do all those properties really add any value?

 

Jeff

 

 

RE: [OT] Ebook Reader

[PENNYCUICK, Chris]

A coworker's father runs this site on the subject 

http://www.ebookanoid.com  

Chris.




From: ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Burstin
Sent: Wednesday, 25 August 2010 1:05 AM
To: ozDotNet
Subject: [OT] Ebook Reader


I'm thinking about getting an ebook reader and was wondering about
peoples experience with the different ones available. 

My wife will be using it too, and she has a serious vision impairment,
so ease of use and readability are the highest priorities for me.

Any thoughts/comments appreciated.

Cheers
Dave

Re: [OT] Ebook Reader

[Filip Kratochvil]

Dave,

With the Cybook bookmarks are easy to make, navigating to them just means
skipping one by one. With novels you are likely to have 1 or 2 so that
should be easy, I gave up on putting more bookmarks in the technical books.
As far as making notes, I always make notes in my 'paper' books but can't do
it with the Cybook.
The Cybook also doesn't have wifi so if you want to read newspapers you have
to sync with some rss reader on you computer - too much of a paint so I
never tried.
As I said before, great for reading novels, not so great for technical books
- in my opinion.
If you are based in Melbourne, let me know off the list and we can arrange
to meet so you can have a look at my Cybook if you like.

HTH,
Filip


On 25 August 2010 09:30, David Burstin  wrote:

> For me, I would like to be able to read newspapers, but the main use will
> be to read technical books and novels. I have a few pdfs but have not
> purchased many ebooks as I haven't had a reader and don't really like
> reading a lot on the laptop/desktop. So, I guess I will be reading mainly
> pdfs and whatever format any ebooks I buy come in.
>
> The other thing I'm interested in is ease of navigation and the ability to
> write notes. Do any of you write notes onto books you are reading? Is it
> easy to search? Navigate to a particular page? Create bookmarks?
>
> I have zero experience with using any of the readers - I've never seen one
> "in the wild" - so any suggestions are appreciated.
>
> I'm leaning towards the Kindle, but am happy to be steered elsewhere.
>
> Cheers
> Dave
>
>
> On Wed, Aug 25, 2010 at 8:47 AM, Filip Kratochvil wrote:
>
>> I have the Cybook Gen3 from Bookeen (
>> http://www.bookeen.com/en/cybook/?id=3) and I'm very happy with it. It
>> uses the same hardware as the eSlick (http://www.foxitsoftware.com/ebook/)
>> but has different software/firmware. Very easy to use and change font size
>> and very easy on the eyes.
>>
>> I tend to convert PDFs to a mobipocket / epub even though the Cybook
>> supports reflowable PDFs (
>> http://news.softpedia.com/news/Adobe-Brings-Reflowable-PDF-to-Mobile-Devices-104649.shtml)
>> If you have lot of books in PDF, I'd suggest looking for device that
>> supports it. Converting from PDF does have it's own issues and the results
>> vary, so I prefer to find books already in mobile format.
>>
>> I think the ebook readers are great for reading non-technical books. With
>> the computer books that I read, I like to be able to flick quickly to
>> certain page and that is not that easy with ebook readers. Dealing with
>> large flow chart, diagrams, UML is also something to consider.
>>
>> HTH,
>> Filip
>>
>>
>>
>> On 25 August 2010 01:04, David Burstin  wrote:
>>
>>> I'm thinking about getting an ebook reader and was wondering about
>>> peoples experience with the different ones available.
>>>
>>> My wife will be using it too, and she has a serious vision impairment, so
>>> ease of use and readability are the highest priorities for me.
>>>
>>> Any thoughts/comments appreciated.
>>>
>>> Cheers
>>> Dave
>>>
>>
>>
>

Re: [OT] Ebook Reader

[David Burstin]

For me, I would like to be able to read newspapers, but the main use will be
to read technical books and novels. I have a few pdfs but have not purchased
many ebooks as I haven't had a reader and don't really like reading a lot on
the laptop/desktop. So, I guess I will be reading mainly pdfs and whatever
format any ebooks I buy come in.

The other thing I'm interested in is ease of navigation and the ability to
write notes. Do any of you write notes onto books you are reading? Is it
easy to search? Navigate to a particular page? Create bookmarks?

I have zero experience with using any of the readers - I've never seen one
"in the wild" - so any suggestions are appreciated.

I'm leaning towards the Kindle, but am happy to be steered elsewhere.

Cheers
Dave

On Wed, Aug 25, 2010 at 8:47 AM, Filip Kratochvil wrote:

> I have the Cybook Gen3 from Bookeen (
> http://www.bookeen.com/en/cybook/?id=3) and I'm very happy with it. It
> uses the same hardware as the eSlick (http://www.foxitsoftware.com/ebook/)
> but has different software/firmware. Very easy to use and change font size
> and very easy on the eyes.
>
> I tend to convert PDFs to a mobipocket / epub even though the Cybook
> supports reflowable PDFs (
> http://news.softpedia.com/news/Adobe-Brings-Reflowable-PDF-to-Mobile-Devices-104649.shtml)
> If you have lot of books in PDF, I'd suggest looking for device that
> supports it. Converting from PDF does have it's own issues and the results
> vary, so I prefer to find books already in mobile format.
>
> I think the ebook readers are great for reading non-technical books. With
> the computer books that I read, I like to be able to flick quickly to
> certain page and that is not that easy with ebook readers. Dealing with
> large flow chart, diagrams, UML is also something to consider.
>
> HTH,
> Filip
>
>
>
> On 25 August 2010 01:04, David Burstin  wrote:
>
>> I'm thinking about getting an ebook reader and was wondering about peoples
>> experience with the different ones available.
>>
>> My wife will be using it too, and she has a serious vision impairment, so
>> ease of use and readability are the highest priorities for me.
>>
>> Any thoughts/comments appreciated.
>>
>> Cheers
>> Dave
>>
>
>

Re: [OT] Ebook Reader

[Filip Kratochvil]

I have the Cybook Gen3 from Bookeen (http://www.bookeen.com/en/cybook/?id=3)
and I'm very happy with it. It uses the same hardware as the eSlick (
http://www.foxitsoftware.com/ebook/) but has different software/firmware.
Very easy to use and change font size and very easy on the eyes.

I tend to convert PDFs to a mobipocket / epub even though the Cybook
supports reflowable PDFs (
http://news.softpedia.com/news/Adobe-Brings-Reflowable-PDF-to-Mobile-Devices-104649.shtml)
If you have lot of books in PDF, I'd suggest looking for device that
supports it. Converting from PDF does have it's own issues and the results
vary, so I prefer to find books already in mobile format.

I think the ebook readers are great for reading non-technical books. With
the computer books that I read, I like to be able to flick quickly to
certain page and that is not that easy with ebook readers. Dealing with
large flow chart, diagrams, UML is also something to consider.

HTH,
Filip


On 25 August 2010 01:04, David Burstin  wrote:

> I'm thinking about getting an ebook reader and was wondering about peoples
> experience with the different ones available.
>
> My wife will be using it too, and she has a serious vision impairment, so
> ease of use and readability are the highest priorities for me.
>
> Any thoughts/comments appreciated.
>
> Cheers
> Dave
>

RE: [OT] Ebook Reader

[Ken Schaefer]

What type of books will you reading? Do you need to order books directly from 
the reader, or are you happy to buy on your PC and transfer? How important is 
it that the store have Australian rights (i.e. you can easily buy using an 
Australian CC?)

The Sony models are the classiest (I have an older PRS-505 model). They have a 
metal body, leather cover. However the Sony eBook store doesn't exist in Aus, 
so you need to find alternate online book stores to buy books. If you just want 
to read magazines, newspapers etc on the device (which is what I used it for) 
then Calibre will get this for you.

Otherwise, you can't beat the Amazon Kindle (either the regular edition, or the 
DX version if you have a lot of PDFs to read). I would recommend the DX if you 
have PDFs that have been printed to A4 (or Letter) size, as the smaller reader 
(regular Kindle, Sony, B&N Nook) can't really cope with the larger size.

The Kindle has the advantage of free 3G worldwide (and a basic browser built 
in). I have the DX for my PDFs, but last night ordered a few free books 
(Sherlock Holmes etc.). Delivered for free direct to the device.

Cheers
Ken

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Burstin
Sent: Tuesday, 24 August 2010 11:05 PM
To: ozDotNet
Subject: [OT] Ebook Reader

I'm thinking about getting an ebook reader and was wondering about peoples 
experience with the different ones available.

My wife will be using it too, and she has a serious vision impairment, so ease 
of use and readability are the highest priorities for me.

Any thoughts/comments appreciated.

Cheers
Dave

[OT] Ebook Reader

[David Burstin]

I'm thinking about getting an ebook reader and was wondering about peoples
experience with the different ones available.

My wife will be using it too, and she has a serious vision impairment, so
ease of use and readability are the highest priorities for me.

Any thoughts/comments appreciated.

Cheers
Dave

Re: VS2010 and SDK 7.0A and 7.1

[.net noobie]

http://www.intrepidstudios.com/blog/2010/7/11/debug-your-net-web-project-with-iis-express-t.aspx



On Mon, Aug 23, 2010 at 6:03 PM, Stephen Liedig  wrote:

> I thought 7.1 was aligned with .NET 4 whereas 7.0A was still 3.5 SP1? Could
> be mistaken though.
>
>
> On 23 August 2010 01:05, Greg Keogh  wrote:
>
>>  I’ve finally upgraded to Visual Studio 2010 and it all seems to be
>> working well. I haven’t had time to look into the snazzy new features yet,
>> as I’ve been bogged down getting my hundred or so projects all upgraded and
>> working. If anyone has favourite productivity tips and tricks for VS2010,
>> let me know. I’ll search for articles later when I get time.
>>
>>
>>
>> I went looking for FxCop, but there seems to be a bug in the web pages
>> (like 
>> HERE)
>> where you click the download link and it starts to download the readme.txt
>> file. Then I read that FxCop 10 is included in the latest SDK. In the SDK
>> 7.0A that’s installed with VS2010 I can only find the old 1.36 FxCop. Then I
>> see that SDK 7.1 is available as a 567MB ISO download (which hasn’t been
>> posted to me yet, so I’m download it).
>>
>>
>>
>> I’m just getting a bit worried about all these SDKs. 7.0A came with VS2010
>> and it seems to be glued to using it. I had to install 6.1 so tools like
>> tlbimp could use Framework 2. Now 7.1 is downloading.
>>
>>
>>
>> This article on 
>> 7.1tells
>>  me how good it will be, but I can’t find any clear explanation of the
>> relationship between 7.0A, 7.1 and VS2010. Can anyone enlighten me?
>>
>>
>>
>> Cheers,
>>
>> Greg
>>
>
>