• Michael (unregistered) in reply to Farleigh
    Farleigh:
    That being said, public fields and properties in your goofy language have the same syntax, so I suppose all you have to do is recompile everything that depends on you....
    Python only require you recompile the one file where the class is defined. I'm not sure about .NET languages, maybe someone can answer this?
  • Torus (unregistered)

    Everyone argues that you could just change it from a public field to a property later when they are young and inexperienced. For some, it takes experience to change that point of view. For me, it took changing a public field to a property, then running make and ending up with a error count in the middling 5 digits. That was fun.

  • Michael (unregistered) in reply to Smash King
    Smash King:
    And some whined that getters and setters take up some space. Why, are you so bothered that you'll hit 'page down' a few more times?
    I think this is an important misconception that many programmers have. Adding more lines of code that aren't necessary wastes time reading the code and makes it harder to understand. Throughout this thread I'm trying to understand if maybe those lines of code (or few extra characters) to make it a property ARE necessary, and there are some interesting arguments.
  • csrster (unregistered)

    The real WTF is that some people think that public setters and getters are a form of encapsulation. They're not. They're a way of exposing the contents of an object through its API, which breaks encapsulation. Sometimes it's necessary, but extensive use of public accessors and modifiers is very often a sign of bad design.

  • Michael (unregistered) in reply to Torus

    [quote user = "Torus"]Everyone argues that you could just change it from a public field to a property later when they are young and inexperienced. For some, it takes experience to change that point of view. For me, it took changing a public field to a property, then running make and ending up with a error count in the middling 5 digits. That was fun.[/quote] What language were you using? What caused those errors? Will this issue occur in a language like C#?

  • (cs) in reply to Michael
    Michael:
    Is there any reason to go ahead and make this field a property right now?
    You answered your own question right before you asked it:
    Michael:
    It's true, maybe someday I'll want to do some fancy tricks with the field and may want it to be a property, but not today.
  • Michael (unregistered) in reply to Code Dependent
    Code Dependent:
    Michael:
    Is there any reason to go ahead and make this field a property right now?
    You answered your own question right before you asked it:
    Michael:
    It's true, maybe someday I'll want to do some fancy tricks with the field and may want it to be a property, but not today.
    My real question here is why I can't easily go ahead and change it to a property later on (as you can in python for example, at least as far as I can tell).
  • Farleigh (unregistered) in reply to csrster

    Yes, but getters/setters can be a controlled break in encapsulation with validation and control of what gets changed rather than an all out do whatever you want type break.

    You can always return a copy in a getter and validate like crazy in a setter.... Public field? not so much....

  • Michael (unregistered) in reply to CaptainObvious
    CaptainObvious:
    Look, it's quite obvious when using .Net.

    A field is stored in the metadata as a Field and a property is a Property.

    Changing a Field to a Property changes the metadata (which is part of the external interface of your class) thus potentially affecting consumers of your class.

    Design properly and avoid any potential issues. Is it really that much harder to type

    public string Name {get;set;};

    than

    private string _name;

    ???

    How does changing that metadata affect consumers of the class? This sounds like something I'm not familiar with; can you explain it or provide a link? I guess I could see if the consumer used reflection it might affect them, but other than that is there any impact on consumers?

  • Tobias Brox (unregistered) in reply to Mike D.

    [quote Mike.D] I'm wondering how this is done in Perl? Just one way to do it, please, I'm sure there are more. ^_- [/quote]

    It's quite long time since I've programmed perl ... but AFAIR, it was possible to define a generic method that would be executed when a non-existent method was called. I think I once wrote a class where a call to getName, getWeight, setName, setSomethingElse etc would be caught and would perform as a default getter/setter method.

  • SkittlesAreYum (unregistered) in reply to Michael
    Michael:
    Many people are posting many useful things that can be done with properties. I know all that, you can do all sorts of great things with them. But suppose you have a field in an object that you need to access like a regular public field with no validation rules. It's true, maybe someday I'll want to do some fancy tricks with the field and may want it to be a property, but not today. Is there any reason to go ahead and make this field a property right now? So far the valid reasons (for languages with properties like C#) I've seen are:
    1. Naming conventions are sometimes different for properties and public fields, so you don't want to go changing them later.

    2. You can more easily set a breakpoint to catch when a property is changing or being read. (Though in many IDEs/debuggers this is possible without using a property.)

    I don't find either of these arguments completely convincing, though people have different programming styles and I'm not saying they're completely UNconvincing, so I understand if people want to use poperties for these reasons. I want to know if there are any other reasons to make a normal public field into a property preemptively? Is there something else I'm missing?

    Benefits of properties vs public fields:

    • Easy to add code in the future

    Disadvantages:

    • NONE

    If there are only potential advantages and no disadvantages, why not just make them all properties? You may not see much of a reason to do so, but you should see even less of a reason to not do so.

  • Michael (unregistered) in reply to SkittlesAreYum
    SkittlesAreYum:
    Benefits of properties vs public fields: * Easy to add code in the future

    Disadvantages:

    • NONE

    If there are only potential advantages and no disadvantages, why not just make them all properties? You may not see much of a reason to do so, but you should see even less of a reason to not do so.

    My real question wasn't phrased well, I think. Isn't it easy to add code to a public field in the future as well? You just change it to a property at that time and go for it. Or is there some reason it's hard to change it that I'm not aware of?

  • Jon (unregistered) in reply to Michael
    Michael:
    Smash King:
    And some whined that getters and setters take up some space. Why, are you so bothered that you'll hit 'page down' a few more times?
    I think this is an important misconception that many programmers have. Adding more lines of code that aren't necessary wastes time reading the code and makes it harder to understand. Throughout this thread I'm trying to understand if maybe those lines of code (or few extra characters) to make it a property ARE necessary, and there are some interesting arguments.
    Not sure about other languages, but C# lets you define a property in a single line, and even specify who has access:
    public bool IsThisAnInstance { get; private set; }
    So there is no real trade-off.

    From reading that Python code earlier I'd definitely start with public fields in that language, if only because it would be readable then. ;)

  • orkybash (unregistered) in reply to Delmania

    Been a while since I used c++ but isn't inline incompatible with dynamic binding?

    At any rate, great explanation.

  • Michael (unregistered) in reply to Jon
    Jon:
    Not sure about other languages, but C# lets you define a property in a single line, and even specify who has access: public bool IsThisAnInstance { get; private set; }

    So there is no real trade-off.

    From reading that Python code earlier I'd definitely start with public fields in that language, if only because it would be readable then. ;)

    You're right, it's just a few characters, it's not a big deal. But it is a few extra characters. So why do it if you don't need it? Sure, if you need a private set, then you need it, but if not?

  • Fennec (unregistered)

    The best way to do getters and setters is to have some dog-easy-to-set-up default getters and setters which you can install on your code for Absolutely Free or Pretty Darned Close, and then it's not a PITA either way.

    Of course, some languages make this easier than others (hug perl).

  • Matthew Watson (unregistered) in reply to Michael
    Michael:
    Jon:
    Not sure about other languages, but C# lets you define a property in a single line, and even specify who has access: public bool IsThisAnInstance { get; private set; }

    So there is no real trade-off.

    From reading that Python code earlier I'd definitely start with public fields in that language, if only because it would be readable then. ;)

    You're right, it's just a few characters, it's not a big deal. But it is a few extra characters. So why do it if you don't need it? Sure, if you need a private set, then you need it, but if not?

    If you're using the shorthand {get; private set;} then if you just have {get;} you'll never be able to set the field, not even in the defining class.

  • Jon (unregistered) in reply to Michael
    Michael:
    Jon:
    Not sure about other languages, but C# lets you define a property in a single line, and even specify who has access: public bool IsThisAnInstance { get; private set; }

    So there is no real trade-off.

    From reading that Python code earlier I'd definitely start with public fields in that language, if only because it would be readable then. ;)

    You're right, it's just a few characters, it's not a big deal. But it is a few extra characters. So why do it if you don't need it? Sure, if you need a private set, then you need it, but if not?
    More a question of future damage mitigation than 'need' I suspect. Like anything else in programming, the major factor would be the language. In C#, you'd go with properties from the start for reasons mentioned already (reflection/binding, it's easy anyway etc). In other languages, maybe not.

    The question is - how does going from a field to a property affect consumers in that specific language. One thing I have learned (from reading this site if nothing else) is that the fewer changes you have to make later, the better. So perhaps it's better to put a bit more effort in now and know exactly how your properties will be accessed than leave it til later and possibly break things you weren't even aware of (back to reflection!).

  • nonleet (unregistered)

    It's interesting that no one has mentioned one of the main benefits of explicit get/set. I have been caught many times by a simple typo in code

    if ( object.Value = "whatever" ) { ... }

    As a public element, I have successfully set the value . . .

  • Mark S. (unregistered)

    Another advantage of getters/setters is in multi-threading. If I need to access a field in multiple threads, then I can add the synchronization into the getter/setter. Otherwise I have to add in synchronization in every place that accesses the variable.

  • (cs)

    I don't know C#. But coming from C++, what about taking pointers of those fields having getters and setters? Can you do that?

  • (cs) in reply to csrster
    csrster:
    The real WTF is that some people think that public setters and getters are a form of encapsulation. They're not. They're a way of exposing the contents of an object through its API, which breaks encapsulation. Sometimes it's necessary, but extensive use of public accessors and modifiers is very often a sign of bad design.
    Nice trolling there. Are you sure you're not really TopCod3r?
  • Michael (unregistered) in reply to Jon
    Jon:
    The question is - how does going from a field to a property affect consumers in that specific language. One thing I have learned (from reading this site if nothing else) is that the fewer changes you have to make later, the better. So perhaps it's better to put a bit more effort in now and know exactly how your properties will be accessed than leave it til later and possibly break things you weren't even aware of (back to reflection!).
    Good point, especially about how it depends on what language you're working on. So, I'd say in C# I have this list of reasons why one might make a property instead of a public field even if you think you have no need for the features a property adds:
    1. You may have a naming convention that differs for public fields and properties, and don't want to have to change all the names later if a property becomes necessary.

    2. You can more easily set a breakpoint to catch when a property is changing or being read. (Though in many IDEs/debuggers this is possible without using a property.)

    3. Various frameworks may only bind to properties, so in general there could be features that are not accessible with public fields that would be accessible with properties.

    4. If consumers of the class are using reflection to access properties and fields, changing a property to a field later on will affect them in unpredictable ways.

    Of these, I find the 4th point the most convincing, as you seem to as well. Though even there, it would be a pretty stupid consumer that gets mixed up when you add a new property. I suspect such stupid consumers are also going to be surprised when you suddenly start throwing validation errors (and in general I expect throwing validation errors where you didn't before to be quite disruptive). So I'm still not completely convinced. But I admit the list is getting longer, and it's easy to see how someone could be convinced. And you're right, in C# it's just a few characters, it's hard to argue against it.

  • (cs) in reply to Delmania
    Delmania:
    In C++, you just declare the accessors and mutators as inline which enables you to maintain the benefits of encapsulation, but still removes the context switching.
    On the other hand, you totally lose things like the ability to maintain even the semblance of a stable ABI for the class. Guess that's why C++ programmers have to recompile everything so often...
  • Torus (unregistered)

    Wow, I can't believe nobody answered poor Michaels question, even though he asked it like 20 bloody times.

    The reason you can't "just change it later" and the reason for all my errors is from OTHER CLASSES ACTUALLY USING THEM.

    Sure, if you have a class that is not used at all, ever, then you can change it later without a problem. If, however, you have a thousand other classes, that all do something like

    if (myClass.booleanFlag) { ....

    and then you make booleanFlag private, and write getBooleanFlag and setBooleanFlag, then every single one of these other classes will not compile anymore because they are trying to access a private or possibly even nonexistant field. That's why you can't just change a field to a property later without sometimes tons of trouble. Again, that's only true if you actually use those classes.

  • Joseph Baggett (unregistered) in reply to Tobias Brox

    Depending on the language and the use, have property getters/setters are needed for things like databinding because it uses reflection.

    The fact that even if properties have private members to be used within the property makes it more maintable code in the long run.

    Using code generation is smart... why wouldn't you want to?

  • (cs) in reply to Shambo
    Shambo:
    A good code based WTF that made me laugh... ahh.. just like the good old days.
    A good code based WTF that made me cringe ...

    The truly good ones have that effect on me.

  • Anon (unregistered) in reply to Torus
    Torus:
    Wow, I can't believe nobody answered poor Michaels question, even though he asked it like 20 bloody times.

    The reason you can't "just change it later" and the reason for all my errors is from OTHER CLASSES ACTUALLY USING THEM.

    Sure, if you have a class that is not used at all, ever, then you can change it later without a problem. If, however, you have a thousand other classes, that all do something like

    if (myClass.booleanFlag) { ....

    and then you make booleanFlag private, and write getBooleanFlag and setBooleanFlag, then every single one of these other classes will not compile anymore because they are trying to access a private or possibly even nonexistant field. That's why you can't just change a field to a property later without sometimes tons of trouble. Again, that's only true if you actually use those classes.

    I think Michael was probably assuming a language where switching from a field to a property could be done without changing the way the consumer accesses it. For example in C# I could do this:

    public bool booleanFlag;

    and you can access it as

    if (myClass.booleanFlag) { ....

    You can later change it a property like this

    private bool _booleanFlag; public bool booleanFlag { get { return _booleanFlag; } set { // do some validation or whatever _booleanFlag = value; } }

    Now you can still access it like this:

    if (myClass.booleanFlag) { ...

    So no difference for you as a consumer of the class.

    However, for all the points that everybody else makes, I think it's still better to make it a property from the start.

  • toth (unregistered) in reply to Torus
    Torus:
    Wow, I can't believe nobody answered poor Michaels question, even though he asked it like 20 bloody times.

    The reason you can't "just change it later" and the reason for all my errors is from OTHER CLASSES ACTUALLY USING THEM.

    Sure, if you have a class that is not used at all, ever, then you can change it later without a problem. If, however, you have a thousand other classes, that all do something like

    if (myClass.booleanFlag) { ....

    and then you make booleanFlag private, and write getBooleanFlag and setBooleanFlag, then every single one of these other classes will not compile anymore because they are trying to access a private or possibly even nonexistant field. That's why you can't just change a field to a property later without sometimes tons of trouble. Again, that's only true if you actually use those classes.

    Yes, but what if, instead of making booleanFlag private, you make it a property? i.e. public boolean booleanFlag {get; set;}? Now, obviously this depends on your language allowing such things, but assuming it does, myClass.booleanFlag would happily compile and run whether booleanFlag were a public field or a property.

  • Michael (unregistered) in reply to Torus
    Torus:
    Sure, if you have a class that is not used at all, ever, then you can change it later without a problem. If, however, you have a thousand other classes, that all do something like

    if (myClass.booleanFlag) { ....

    and then you make booleanFlag private, and write getBooleanFlag and setBooleanFlag, then every single one of these other classes will not compile anymore because they are trying to access a private or possibly even nonexistant field. That's why you can't just change a field to a property later without sometimes tons of trouble. Again, that's only true if you actually use those classes.

    A feature of some languages like C#, VB.NET, and python is that you can have properties that look and act almost exactly like public fields. So you could take your booleanFlag, and you don't need to write separate getBooleanFlag and setBooleanFlag routines that consumers need to worry about. You add a get and set routine, but to the consumers it looks just like a regular public field, and when they get or set the field, those routines are called automatically without consumers even knowing it. So that's not quite the issue for these languages.

  • (cs) in reply to csrster
    csrster:
    The real WTF is that some people think that public setters and getters are a form of encapsulation. They're not. They're a way of exposing the contents of an object through its API, which breaks encapsulation. Sometimes it's necessary, but extensive use of public accessors and modifiers is very often a sign of bad design.

    This all depends on what the attributes and objects are.

    For instance, if I have a 'telephone' object, what I shouldn't do is use a setter to dial -

    phone.setNumberToDial('555123456');
    phone.dial();
    

    Instead, I should use a method -

    phone.dialNumber('555123456');
    

    But, with the same phone object if I want to turn off the ringer, there's nothing wrong with

    phone.setRinger(false);
    

    So, public accessors are fine, as long as not used as an alternative to good design.

  • (cs) in reply to Delmania
    Delmania:
    In C++, you just declare the accessors and mutators as inline which enables you to maintain the benefits of encapsulation, but still removes the context switching.

    I don't think context switching means what you think it means...

  • (cs) in reply to dkf
    dkf:
    csrster:
    The real WTF is that some people think that public setters and getters are a form of encapsulation. They're not. They're a way of exposing the contents of an object through its API, which breaks encapsulation. Sometimes it's necessary, but extensive use of public accessors and modifiers is very often a sign of bad design.
    Nice trolling there. Are you sure you're not really TopCod3r?

    hmmm, I nearly fell for that one...my powers are weak...

  • (cs)

    I would have used String.IsNullOrEmpty(SearchParts), but there you go.

  • Samuel A. Falvo II (unregistered)

    The only WTF here is ascribing an action to a getter which simply doesn't belong there. It conditionally changes the control flow of the program, as seen by the user at least. If I found my engineers doing this, I'd can them on the street faster than they can revert their changes.

    In terms of static interpretation, a variable is a niladic function. Referencing a variable will always, to the code reader at least, return a value, whether computed or simply retrieved from a location in memory. Or, it might throw an exception if necessary (e.g., if searchParts == Null, and this violates the invariant of the class, then an exception is definitely the solution to use here). In either case, referencing a variable is taken to be a referentially transparent action. I'd hate to be the poor soul who has to debug this code months or years down the road.

    Throwing an HTTP redirect inside of a getter is spaghetti code, plain and simple. It has no reason for existing there. When reading client code, there is NOTHING to indicate to the reader that a redirect might occur, or under which circumstances.

  • Jay (unregistered)

    In my humble opinion:

    A lot of posters are saying there are no disadvantages to get/set except a couple of extra lines of code, or that this doesn't even count as a disadvantage. I beg to differ. Every extra line of code is one more line that someone has to plow through to understand the program. That's why I write "x+=2" and not "x=x+2" or "x=x+1; x=x+1;". Sure, ONE unnecessary extra line of code in a program is no big deal. But what if my class has twenty fields that interact with the outside world? A minimal get or set function takes four lines on the page (the way I write it anyway, with the braces each on their own line), so twenty pairs of such functions is 160 lines. That's nothing to dismiss. (And yes, I don't like having that much data interacting with the outside world, but it happens. Often.)

    So if I need validation or side effects every time a value is updated or retrieved, sure, I write getters and setters. If I don't need validation or side effects, and there's no reason to believe that I will in the near future, then I just declare the field public and use it.

    Yes, someday the requirements may change and I will have to add getters and setters. Fine. I mostly write in Java, and Eclipse will change all the references to gets and sets with a few clicks of a mouse. If I was writing a package that I expected to distribute as a utility that programmers outside my organization would invoke from their own code, I'd lean a little more to using get/set because I then wouldn't have access to the calling code to do any refactoring.

    In any case, I almost never have to turn a public field into a get/set property. Off the top of my head I can only think of one time in the past decade that I have done this. So sure, I try to write code that is flexible and extensible for future requirements changes. But you can't provide for everything. I plan for what's reasonably likely, and deal with the rest when it comes.

  • Anon (unregistered) in reply to Jay
    Jay:
    In my humble opinion:

    A lot of posters are saying there are no disadvantages to get/set except a couple of extra lines of code, or that this doesn't even count as a disadvantage. I beg to differ. Every extra line of code is one more line that someone has to plow through to understand the program. That's why I write "x+=2" and not "x=x+2" or "x=x+1; x=x+1;".

    I disagree, I think properties with getters and setters can actually aid understanding of the code. For example, if a particular property has a public getter, but a private setter, then you can reasonably conclude that the original programmer explicitly did not expect anybody to set the value outside of this class. If they are both public, then you know that the programmer expected changes to come from outside (or, more likely, just didn't really think about it). Also, although I'd use x+=2; I'd argue that x=x+2; is much more explicit.

  • (cs) in reply to Michael
    Michael:
    CaptainObvious:
    Look, it's quite obvious when using .Net.

    A field is stored in the metadata as a Field and a property is a Property.

    Changing a Field to a Property changes the metadata (which is part of the external interface of your class) thus potentially affecting consumers of your class.

    How does changing that metadata affect consumers of the class? This sounds like something I'm not familiar with; can you explain it or provide a link? I guess I could see if the consumer used reflection it might affect them, but other than that is there any impact on consumers?

    Because now all the consumers must be recompiled to CIL bytecode that uses the get/set functions instead of directly accessing the data. When the JIT compiler turns that bytecode into machine code, it will be inlined and turned into code just as fast as direct access, but the CIL bytecode itself will forever be changed from a stfld/ldfld to callvirt. Therefore, anything that uses it must be recompiled.

    If this was a class library, now you have an unknown number of other class libraries or executables that you must recompile. If you had just used a property in the first place, no recompiling would be necessary, you would simply change the internal code without changing the external interface.

    If this is inside an executable, now every compile unit that uses it must be recompiled. Usually compilers like to skip unchanged compile units for a shorter compile time.

  • Michael (unregistered) in reply to Erzengel
    Erzengel:
    Michael:
    CaptainObvious:
    A field is stored in the metadata as a Field and a property is a Property.

    Changing a Field to a Property changes the metadata (which is part of the external interface of your class) thus potentially affecting consumers of your class.

    How does changing that metadata affect consumers of the class? This sounds like something I'm not familiar with; can you explain it or provide a link? I guess I could see if the consumer used reflection it might affect them, but other than that is there any impact on consumers?

    Because now all the consumers must be recompiled to CIL bytecode that uses the get/set functions instead of directly accessing the data. When the JIT compiler turns that bytecode into machine code, it will be inlined and turned into code just as fast as direct access, but the CIL bytecode itself will forever be changed from a stfld/ldfld to callvirt. Therefore, anything that uses it must be recompiled.

    If this was a class library, now you have an unknown number of other class libraries or executables that you must recompile. If you had just used a property in the first place, no recompiling would be necessary, you would simply change the internal code without changing the external interface.

    If this is inside an executable, now every compile unit that uses it must be recompiled. Usually compilers like to skip unchanged compile units for a shorter compile time.

    Does this mean if I provide a DLL with a class that has a public field and later change that public field to a property that the DLL will no longer work with applications that were compiled using the old version?

  • Michael (unregistered) in reply to Michael
    Michael:
    Erzengel:
    Michael:
    How does changing that metadata affect consumers of the class? This sounds like something I'm not familiar with; can you explain it or provide a link? I guess I could see if the consumer used reflection it might affect them, but other than that is there any impact on consumers?
    If this was a class library, now you have an unknown number of other class libraries or executables that you must recompile. If you had just used a property in the first place, no recompiling would be necessary, you would simply change the internal code without changing the external interface.
    Does this mean if I provide a DLL with a class that has a public field and later change that public field to a property that the DLL will no longer work with applications that were compiled using the old version?
    Well, I just checked that and it's true. The old executable won't work with the new class library. That's the most convincing reason I've seen yet. In C# at least, you really can't freely convert between properties and public fields if you want classes to be usable by external consumers. That's another vote for python in my book, and it's good to know when writing C# code.
  • Jeh-fuh-fuh (unregistered) in reply to Matthew Watson
    Matthew Watson:
    Well C# let's you just do:

    public int SomeProperty {get; set; }

    And then you can add any logic later on as the need arises.

    Also, people are overlooking a very useful thing about using public properties instead of public fields: You can set a debugger breakpoint in the property setter to determine when and by what it's being set. Try doing that with a public field...

    Try learning how to use a debugger ;)

  • Matthew Watson (unregistered) in reply to Jeh-fuh-fuh
    Jeh-fuh-fuh:
    Matthew Watson:
    Well C# let's you just do:

    public int SomeProperty {get; set; }

    And then you can add any logic later on as the need arises.

    Also, people are overlooking a very useful thing about using public properties instead of public fields: You can set a debugger breakpoint in the property setter to determine when and by what it's being set. Try doing that with a public field...

    Try learning how to use a debugger ;)

    Try learning how to use C#. You CANNOT set a memory change breakpoint when you're debugging C# code. Duh!

  • (cs) in reply to Michael
    Michael:
    Well, I just checked that and it's true. The old executable won't work with the new class library. That's the most convincing reason I've seen yet. In C# at least, you really can't freely convert between properties and public fields if you want classes to be usable by external consumers. That's another vote for python in my book, and it's good to know when writing C# code.

    Thank you for not being helpless.

    I don't know how python handles it, but if it were to use CIL (".net" is actually the Common Instruction Language standard, ECMA 335), for example IronPython, it must be automatically converting fields to properties. That's the only way it would be able to allow the later addition of accessors without recompiling everything dependent upon it.

    You'd have the same problem in C++ even if you used MSVC's __declspec(property) compiler-specific functionality.

    You always have special considerations when making DLLs.

  • Franz Kafka (unregistered) in reply to Delmania
    Delmania:
    fusspawn:
    Agreed, and in the process of pointing out im not as "l337z Coderz" as some of you, How large is the performance hit for doing it with get/set over not bothering.

    Which language? In C++, you just declare the accessors and mutators as inline which enables you to maintain the benefits of encapsulation, but still removes the context switching.

    What context switching? This is a function call or a data access - no context needed.

  • Jeremy (unregistered) in reply to Jeh-fuh-fuh

    It seems like a few people are concerned about the extra lines of code added by getters and setters.

    I've never had a problem with this, but I make extensive use of the code-block minimization feature that I can't recall the name of. Y'know, the little +/- that you click to expand or collapse a section of code.

    I tend to code with related sections separated into regions and with most sections collapsed by default. I find that this helps me find relevant sections more quickly and consistently than searching through a few hundred lines each time.

    I know that not everyone does it this way; so I'd like to hear some of the advantages that you feel I am missing out on.

  • Isak (unregistered) in reply to Michael
    Michael:
    Code Dependent:
    Michael:
    Is there any reason to go ahead and make this field a property right now?
    You answered your own question right before you asked it:
    Michael:
    It's true, maybe someday I'll want to do some fancy tricks with the field and may want it to be a property, but not today.
    My real question here is why I can't easily go ahead and change it to a property later on (as you can in python for example, at least as far as I can tell).

    Because changing from field to property (in C#/.NET) breaks the binary interface (ABI).

    All compiled code using your class will break if you change - even if they have the same name. The compiler will convert

    public int MyInt { get; set; }

    to

    public int get_MyInt() {... } 

    and

    public void set_MyInt(int value) {...}

    behind the scenes. Other (compiled) .NET code depends on this fact...

  • Michael (unregistered) in reply to Erzengel
    Erzengel:
    Michael:
    Well, I just checked that and it's true. The old executable won't work with the new class library. That's the most convincing reason I've seen yet. In C# at least, you really can't freely convert between properties and public fields if you want classes to be usable by external consumers. That's another vote for python in my book, and it's good to know when writing C# code.
    I don't know how python handles it, but if it were to use CIL (".net" is actually the Common Instruction Language standard, ECMA 335), for example IronPython, it must be automatically converting fields to properties. That's the only way it would be able to allow the later addition of accessors without recompiling everything dependent upon it.

    You'd have the same problem in C++ even if you used MSVC's __declspec(property) compiler-specific functionality.

    You always have special considerations when making DLLs.

    I don't expect much from C++ in general. Personally I mostly use it when I want blazing fast speed and things like properties aren't really on my mind most of the time when I'm optimizing something like that. And you may be right about IronPython, I've never used it so I don't want to spend the time testing it right now. I've mostly used the regular python distribution (I think they call it C Python actually, as opposed to pypy, python written in python).

  • Addison (unregistered)

    Don't laugh. I am working on a project right now where something similar is in place. . . or WAS until I saw it.

    When you added a record you would get redirected to a page that contained only a message telling you that you did it right and it was successful.

    I wonder what better way I could do that. . . ? Hmm. . .

  • jfp (unregistered) in reply to Farleigh
    The real WTF is that you guys are actually advocating using public fields over public accessor methods.

    Agree. Accessor methods reduce code complexity because they can provide guarantees about what users of the object can and can't do. Public fields are insane because any code anywhere could be doing anything with them. If someone has actually worked on a medium or large scale project and still thought public fields were a good idea (outside of edge cases) I'd say they were too retarded for software development.

  • Jeh-fuh-fuh (unregistered) in reply to Matthew Watson
    Matthew Watson:
    Jeh-fuh-fuh:
    Matthew Watson:
    You can set a debugger breakpoint in the property setter to determine when and by what it's being set. Try doing that with a public field...
    Try learning how to use a debugger ;)

    Try learning how to use C#. You CANNOT set a memory change breakpoint when you're debugging C# code. Duh!

    That's just incorrect, but nice try. Conditional breakpoints are your friends. Among those conditions are "when changed" which most definitely can be set on a member variable. Check it out sometime.

Leave a comment on “Try Doing That with a Field”

Log In or post as a guest

Replying to comment #:

« Return to Article