Ah, the beauty of C#. What you haven't yet discove...
Bill Mill · 2007-07-18T19:42:00
Ah, the beauty of C#. What you haven't yet discovered is that the accessors do have an important reason for existance. The reason?
At the assembly level, "employee.Name" the property is not the same as "employee.Name" the public attribute.
If you link and build against an assembly A, then version 2 of that assembly changes a public string into a property, you will have to recompile your code to work with the new assembly, even though your source doesn't change at all.
Isn't that a lovely decision?
you could always declare instance variables as pub...
Anonymous · 2007-07-18T20:03:00
you could always declare instance variables as public to get direct access (though every C# programmer would scream at you).
What I hate more than getters and setters are ca...
Anonymous · 2007-07-18T20:42:00
What I hate more than getters and setters are camelCaseVariables and camelCaseFunctions.
I do agree that *empty* getters and setters are pointless, but what if they were (mostly) not empty? In that case, standardizing on their use would be a good thing, in order to establish consistency within an API / toolkit. Would you agree with that?
Ironically, C#'s Property syntax was originally su...
Anonymous · 2007-07-18T21:42:00
Ironically, C#'s Property syntax was originally supoused to address this problem. Because the getters and setters, in short, the accesors, use direct access syntax, the clients of that class could use its properties regardless of how they are implemented, an explicit accessor would only be written if needed.
But this being Microsoft, many frameworks including ASP and the applications created using Visual Studio, do not treat properties and public fields the same, leaving us writing empty accessors.
So this is not a flaw of C# but of the Visual Studio IDE and the C# developer culture surrounding it. In the end the blame is to Microsoft, as usual.
Now if you want to see a language that Really Does Not Get It(tm), look at Ruby, where access to instance attributes is impossible by design.
Since it is even more restricted than C#, the need for a quick way of writting accessors was strong, and since Ruby's designer isn't stupid he provided a way to write (one or more) accessor(s) in a single line. It is still a kludge.
The flaw in Ruby actually runs deeper than that. Ruby does not allows access to instance variables because it doesn't has syntax for accessing the inner namespace of an object, period.
The '.' operator in Ruby, what we call the getattr operator is actually the "send message" operator, it only works on methods and it always __call__ them (in python parlance).
Ruby has an operator to get an object from inside another object, it is the '::' operator, but it only works on classes.
Unlike Python, in Ruby classes are classes, methods are methods and variables are variables, in Python, everything is an object.
But Everybody(tm) knows Ruby is more object oriented than Python, of course.
But I wish C# had a shortcut to write properties like in Ruby does.
Is it possible to convert a direct-access attribut...
Anonymous · 2007-07-19T00:19:00
Is it possible to convert a direct-access attribute over to a getter/setter implementation in C# without having to recompile/link code which uses the class?
I was sold on direct access in Python once I saw that I could switch to a property that caused a function to be called when the attribute was accessed. Then there was no penalty for using direct access now, since a getter/setter could always be implemented later.
Oop, looks like previous commenter answered my que...
Anonymous · 2007-07-19T01:44:00
Oop, looks like previous commenter answered my question. Too bad that switching between properties and public attributes in C# requires relinking...
I have in fact created a class whose attributes ar...
Steve · 2007-07-19T02:04:00
I have in fact created a class whose attributes are public, precisely because it seems the most straightforward way to allow attribute access. And I don't care who screams at me for it.
The idea that changing a plain attribute to a property requires recompilation of the client code despite there being no change in its source strikes me as, well, shall we say bizarre. But it does, I suppose, explain part of the urge to use getters and setters, and I can appreciate the underlying implementation reasons for it (without praising the decisions that led to it).
I don't actually think C# is by any means the most horrible language I have come across, and they all have warts. It's giving me a new appreciation for some of Python's good design decisions.
In Java, changing from direct attribute access to ...
Anonymous · 2007-07-19T11:16:00
In Java, changing from direct attribute access to getter/setter access requires changing client code from foo.bar to foo.bar(). IIRC this is the reason recommended Java practice is to always use getters and setters - there is no easy upgrade path.
Scott Meyer's classic (1992) book "Effective C++" strongly recommends using functions to access data members because it allows you to change the implementation without changing the interface. This is essentially the same argument used for Java, so it has been around for a long time.
Thanks, Kent. It seems strange that programmers wo...
Steve · 2007-07-19T12:52:00
Thanks, Kent. It seems strange that programmers would prefer to go to the trouble of using redundant getters and setters rather than being prepared to refactor their clients when a change from attribute to property takes place. The argument also has less force in C# where the syntax, as in Python, remains the same (though see Bill Mill's remarks about the need to recompile the clients after such a change).
I think you have hit the nail about the enterprise...
Anonymous · 2007-07-19T21:18:00
I think you have hit the nail about the enterprisey programmers and... whatever you call us.
Remember, enterprisey desing is ruled by the CYA principle.
Ah, the beauty of C#. What you haven't yet discove...
Bill Mill · 2007-07-18T19:42:00
Ah, the beauty of C#. What you haven't yet discovered is that the accessors do have an important reason for existance. The reason?At the assembly level, "employee.Name" the property is not the same as "employee.Name" the public attribute.
If you link and build against an assembly A, then version 2 of that assembly changes a public string into a property, you will have to recompile your code to work with the new assembly, even though your source doesn't change at all.
Isn't that a lovely decision?
you could always declare instance variables as pub...
Anonymous · 2007-07-18T20:03:00
you could always declare instance variables as public to get direct access (though every C# programmer would scream at you).What I hate more than getters and setters are ca...
Anonymous · 2007-07-18T20:42:00
What I hate more than getters and setters are camelCaseVariables and camelCaseFunctions.I do agree that *empty* getters and setters are pointless, but what if they were (mostly) not empty? In that case, standardizing on their use would be a good thing, in order to establish consistency within an API / toolkit. Would you agree with that?
Ironically, C#'s Property syntax was originally su...
Anonymous · 2007-07-18T21:42:00
Ironically, C#'s Property syntax was originally supoused to address this problem. Because the getters and setters, in short, the accesors, use direct access syntax, the clients of that class could use its properties regardless of how they are implemented, an explicit accessor would only be written if needed.But this being Microsoft, many frameworks including ASP and the applications created using Visual Studio, do not treat properties and public fields the same, leaving us writing empty accessors.
So this is not a flaw of C# but of the Visual Studio IDE and the C# developer culture surrounding it. In the end the blame is to Microsoft, as usual.
Now if you want to see a language that Really Does Not Get It(tm), look at Ruby, where access to instance attributes is impossible by design.
Since it is even more restricted than C#, the need for a quick way of writting accessors was strong, and since Ruby's designer isn't stupid he provided a way to write (one or more) accessor(s) in a single line. It is still a kludge.
The flaw in Ruby actually runs deeper than that. Ruby does not allows access to instance variables because it doesn't has syntax for accessing the inner namespace of an object, period.
The '.' operator in Ruby, what we call the getattr operator is actually the "send message" operator, it only works on methods and it always __call__ them (in python parlance).
Ruby has an operator to get an object from inside another object, it is the '::' operator, but it only works on classes.
Unlike Python, in Ruby classes are classes, methods are methods and variables are variables, in Python, everything is an object.
But Everybody(tm) knows Ruby is more object oriented than Python, of course.
But I wish C# had a shortcut to write properties like in Ruby does.
Is it possible to convert a direct-access attribut...
Anonymous · 2007-07-19T00:19:00
Is it possible to convert a direct-access attribute over to a getter/setter implementation in C# without having to recompile/link code which uses the class?I was sold on direct access in Python once I saw that I could switch to a property that caused a function to be called when the attribute was accessed. Then there was no penalty for using direct access now, since a getter/setter could always be implemented later.
Oop, looks like previous commenter answered my que...
Anonymous · 2007-07-19T01:44:00
Oop, looks like previous commenter answered my question. Too bad that switching between properties and public attributes in C# requires relinking...I have in fact created a class whose attributes ar...
Steve · 2007-07-19T02:04:00
I have in fact created a class whose attributes are public, precisely because it seems the most straightforward way to allow attribute access. And I don't care who screams at me for it.The idea that changing a plain attribute to a property requires recompilation of the client code despite there being no change in its source strikes me as, well, shall we say bizarre. But it does, I suppose, explain part of the urge to use getters and setters, and I can appreciate the underlying implementation reasons for it (without praising the decisions that led to it).
I don't actually think C# is by any means the most horrible language I have come across, and they all have warts. It's giving me a new appreciation for some of Python's good design decisions.
In Java, changing from direct attribute access to ...
Anonymous · 2007-07-19T11:16:00
In Java, changing from direct attribute access to getter/setter access requires changing client code from foo.bar to foo.bar(). IIRC this is the reason recommended Java practice is to always use getters and setters - there is no easy upgrade path.Scott Meyer's classic (1992) book "Effective C++" strongly recommends using functions to access data members because it allows you to change the implementation without changing the interface. This is essentially the same argument used for Java, so it has been around for a long time.
Thanks, Kent. It seems strange that programmers wo...
Steve · 2007-07-19T12:52:00
Thanks, Kent. It seems strange that programmers would prefer to go to the trouble of using redundant getters and setters rather than being prepared to refactor their clients when a change from attribute to property takes place. The argument also has less force in C# where the syntax, as in Python, remains the same (though see Bill Mill's remarks about the need to recompile the clients after such a change).I think you have hit the nail about the enterprise...
Anonymous · 2007-07-19T21:18:00
I think you have hit the nail about the enterprisey programmers and... whatever you call us.Remember, enterprisey desing is ruled by the CYA principle.
Page 1 of 1
Back to post