Back to C#.
-
-
Wow! An actual Troglodyte!
Wot Me?
-
I ran away from C# and got back to real programming some five years ago, and have been happy ever since. Today I found out I was assigned on a C# web project. Welcome back view states, postbacks, properties, dispose patterns and other "joys" I hoped I would never see again :) On the bright side, I can still use vim for editing code.
-
I jumped at C# as a way to get shot of VB but some of it does make me for the shear simplicity of ANSI C which I still have to for Microcontrollers and some low level work on processor. The biggest pain I find is the lack of '&' for referencing type. For sheer speed I will still tryout something in VB and then rewrite it in C#. What are the main issues (other than it's not C++), why is it not real programming, just interested thats all! Glenn
glennPattonWork wrote:
What are the main issues (other than it's not C++), why is it not real programming, just interested thats all!
Shouldn't you have asked the OP that?
glennPattonWork wrote:
The biggest pain I find is the lack of '&' for referencing type
Are you talking about C#? Everything in C# is basically passed by reference (more like passed by pointer). You can also use the
refkeyword to pass things into functions and allow the function to set the value of that variable. You can also use theoutkeyword, which has a similar but slightly different purpose. -
Wow! An actual Troglodyte!
Michael K Gray wrote:
Troglodyte
At first, I thought you were saying "troglobyte". Didn't know this word. :thumbsup:
-
Michael K Gray wrote:
Troglodyte
At first, I thought you were saying "troglobyte". Didn't know this word. :thumbsup:
Troglobyte Cool! that pretty much sums me up as a coder, mind you I'm only a Windows coder as I wasn't at the meeting when the last guy we had ran screaming from the building! Give IC's, Resistors, Capacitors & Inductors; I'm a hardware guy really! So I propose the following definition "Troglobyte: Coder who gets lumbered with a job nobody else will do & Skill set that needs updating" Any views! Glenn
-
You are the first person I've ever seen don't liking Properties. They are syntactic sugar but they make the code concise and understandable. Yes they are methods, you know they are, they start with a capital letter, but what's the problem about that?
I don't like properties either - syntactic sugar for functions. And don't get me started on "automatic" properties... let's execute all of the mechanics of calling a function, but don't let the programmer do any work in it :doh:. The rationale of "don't expose fields" was so that any business logic can be encapsulated in the property get/set functions - but automatic properties might as well be a public field and a block of NOP's
-- What's a signature?
-
I don't like properties either - syntactic sugar for functions. And don't get me started on "automatic" properties... let's execute all of the mechanics of calling a function, but don't let the programmer do any work in it :doh:. The rationale of "don't expose fields" was so that any business logic can be encapsulated in the property get/set functions - but automatic properties might as well be a public field and a block of NOP's
-- What's a signature?
No. Automatic properties can have annotations that variables do not. Automatic properties can be used by frameworks in ways variables are not. You just haven't used C# (or java for that matter) enough to see the gains. Try data annotations and silverlight validation, for example.
-
No. Automatic properties can have annotations that variables do not. Automatic properties can be used by frameworks in ways variables are not. You just haven't used C# (or java for that matter) enough to see the gains. Try data annotations and silverlight validation, for example.
Damn, I've been using C# full-time since 1.0 beta back in 2001 and still haven't used it enough to understand, eh? How many LoC's do I have to write before I see?? I'm well aware that many of the decorations can only be applied to properties, but that's a restriction stemming from the initial design rather than a technical one; many attributes can be applied at a field level rather than property, and could quite easily be checked using a either a FieldInfo or a PropertyInfo. The fact that a different design decision was made in some frameworks to use AttributeTargets.Property instead of AttributeTargets.Property|AttributeTargets.Field doesn't alter the underlying fact that the automatic property is wasteful. Of course, whether it's actually noticeable is a different issue!
-- What's a signature?
-
Damn, I've been using C# full-time since 1.0 beta back in 2001 and still haven't used it enough to understand, eh? How many LoC's do I have to write before I see?? I'm well aware that many of the decorations can only be applied to properties, but that's a restriction stemming from the initial design rather than a technical one; many attributes can be applied at a field level rather than property, and could quite easily be checked using a either a FieldInfo or a PropertyInfo. The fact that a different design decision was made in some frameworks to use AttributeTargets.Property instead of AttributeTargets.Property|AttributeTargets.Field doesn't alter the underlying fact that the automatic property is wasteful. Of course, whether it's actually noticeable is a different issue!
-- What's a signature?
Ok, I made some assumptions here and I apologize. Still, the way it is implemented, you *know* that if you need to convert one day your field-equivalent automatic property to a fully-fledged property with logic in the getter and the setter, nothing will break because of this change (because of the logic you implement, of course, something might change). With a conversion from a field to a Property (or even worse from a field to a Getter and a Setter, as in Java), some consumers will break. In the end, it's only some minor extra coding overhead ({get; set;}) to avoid this kind of situations in the future of your code. I think it's worth the effort.
modified on Friday, September 24, 2010 5:32 PM