On 7/22/12 9:52 AM, Bennie Kloosteman wrote:
- Your spending a lot of time making Rust brief yet hear you are writing
a function for every field.. that's a lot of brain dead code.. When C#
started , first they thought properties were a nice to have but later
properties became a representation that means you want to export it .
This allowed objects to control what was exported but without the
internals being exported. So objects in the GUI bind to properties but
not fields , likewise most serialization and ORMs used public
properties to indicate the user wants to export this.. Since it became
so common (and you would most certainly not write professional C# code
without public properties and private fields , ) the new auto property
was introduced to reduce it eg
int field { get ; set; } ; OR
int field { get ; private set; } ;
Which as most of you know generates a hidden field wrapped by public
properties succinctly. This covers 80% of cases but in the other cases
where you need to manipulate it you still need the field and property
Yes, this is the complexity I was referring to. I'd like to try omitting
it and seeing how painful it is.
That said personally I think there is no point having properties and
prop functions unless you can have "private" fields which im not sure
Rust can do as you need a "this" pointer which then makes you an OO
language .
Classes (now structs) do have private fields. Methods have an implicit
(soon to be explicit) "this" pointer.
You are then on the bitc path and you get into a lot of
confusion in whether to use a trait or a class for polymorphism ...
In Rust, there is no class inheritance; your only choice for
polymorphism is traits.
Anyway so what is Rusts position on data encapsulation , how do you
simply hide some of the data without something nasty like hiding it
behind a external lookup function ?
Private fields.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
