Reputation
Top tag
Next privilege 125 Rep.
Vote down
Badges
4
Impact
0 people reached

  • 0 posts edited
  • 1 helpful flag
  • 25 votes cast
12h
comment When are Getters and Setters Justified
All I get from that and your answer is that you don't understand the concept of encapsulation. it also contradicts your assertion that "Having getters and setters does not in itself break encapsulation". That claim is quite different from "they only break encapsulation a little if you only have a few of them". Again, Darrell Teague got it right. You have no response to that because of your lack of expertise in this area.
16h
comment When are Getters and Setters Justified
"How will you provide an interface to a data transfer object then? " -- Such objects should be immutable.
16h
comment When are Getters and Setters Justified
"Having getters and setters does not in itself break encapsulation. What does break encapsulation is having a getter and a setter for every data member (every field, in java lingo)." -- This is obviously nonsense; the percentage of an object's properties that are externally changeable has no bearing on whether encapsulation is broken. The plain fact is that public setters break encapsulation of the value of the property ... any piece of code anywhere can change it at any time. Darrell Teague gets it right ... public setters are bad design.
16h
comment When are Getters and Setters Justified
"you only implement those you need. That's why you use getters and setters instead of public member variables." -- There's no design difference between public setters and public member variables ... you can make member variables public only as needed. Both are poor design for the same reason globals are bad designe -- because control of the value of the property is not localized. Use immutable objects instead -- their properties are only set at time of construction.
16h
comment What is the point of properties?
Despite all the dogma, there is no design advantage of public Type Property { get; set; } over public Type Property;, since the latter can transparently be changed to the former. Both are equally bad because, like globals, any piece of code can change the value of Property, affecting all users of Property. Much preferable are immutable objects, setting the values of properties at the time of construction.
Jul
2
awarded  Autobiographer
Apr
27
comment If null is bad, why do modern languages implement it?
ceylon-lang.org/documentation/spec/html/typesystem.html
Apr
27
comment If null is bad, why do modern languages implement it?
Who wants traps? There are far more general mechanisms ... a precondition on a function/method that asserts that a parameter isn't null lets you take whatever action you want if it is. But for nullable references, the combination of Maybe and non-nullable references is far better because it makes it semantically impossible to have a null where it shouldn't be. And Maybe is just a specific example of a disjunctive type ... take a look at Ceylon, which makes powerful use of them.
Apr
27
comment If null is bad, why do modern languages implement it?
... and which might not, so it takes programmer discipline to always check for null in the right places, and invariably this discipline fails. With Maybe, the compiler/language semantics enforces the discipline. The generated code is the same, but Maybe is safe while nullable references are not. This is what type systems can do for you. You should go learn about it.
Apr
27
comment If null is bad, why do modern languages implement it?
... neither Nothing nor Maybe<T> is a reference type and so cannot be dereferenced. In order to extract a T from Maybe<T> you must test the type first ... this is a compile-time restriction imposed by the semantics of the language and the Maybe type. Thus, it is impossible to dereference null (Nothing). By declaring something as a Maybe<reference> rather than a reference, you have said that this is a thing that might be Nothing, so it is necessary to test the type to see if it is a reference before using it as one. But with T* foo, there is no way to declare which pointers might hold null ...
Apr
27
comment If null is bad, why do modern languages implement it?
Your question is probably meant to be rhetorical, but it just reveals a complete failure to understand or even attempt to understand -- all too common among C programmers who have a good grasp of the hardware level but fail at abstraction. First, on the expense: optimized implementations avoid the extra flag by representing the Nothing case of Maybe<reference type> with an invalid address -- null is a good candidate -- so the representation is identical. But while null is a legal but invalid value for a reference type, so it can be dereferenced, resulting in undefined behavior, ...
Apr
27
comment If null is bad, why do modern languages implement it?
Rust has no null at all and Ceylon has it as a separate type that can be used to compose "reference or null" types but null can never be the value of a reference ... Ceylon has no NullPointerException because such exceptions aren't semantically possible. And these languages are no less powerful for not having null ... but their designs reflect good, modern understanding of type theory. "Instead it allows you to specify which variables are allowed to hold null, and which aren't." -- this is quite wrong ... Option is a union type; no reference variable ever has a value of "Nothing".
Apr
27
comment If null is bad, why do modern languages implement it?
"No, it wouldn't solve the problem -- at least, not without introducing null references all over again." -- Such comments show a complete lack of understanding of type theory.
Apr
27
comment If null is bad, why do modern languages implement it?
Rust follows point 1 -- no null at all. Ceylon follows point 2 -- non-null by default. References that can be null are explicitly declared with a union type that includes either a reference or null, but null can never be the value of a plain reference. As a result, the language is completely safe and there's no NullPointerException because it isn't semantically possible.
Apr
27
comment If null is bad, why do modern languages implement it?
"The technically superior solutions are all more unwieldy " -- No, they aren't; both Rust and Ceylon are counterexamples.
Apr
27
comment If null is bad, why do modern languages implement it?
None of these answers show any understanding of the state of the art. Null has been completely removed from the programming model of Rust. Ceylon has null but it is always safe; there is no NullPointerException or equivalent because it isn't possible for it to occur. This is without any loss of power.
Apr
27
comment If null is bad, why do modern languages implement it?
"that's what parenthesis are for in English" -- "parenthesis" is singular in English.
Apr
27
comment If null is bad, why do modern languages implement it?
"WTF is up with you guys?" -- Intelligence and knowledge. "Of all the things that can and do go wrong with software, trying to dereference a null is no problem at all." -- false. " This is like asking why mathematics has zero, when it causes so many problems for division." -- No, it's nothing like that. " It refers to "no object" in exactly the same way that "zero cows" refers to no cows." -- false. "using Options - does not in fact get rid of null references. Instead it allows you to specify which variables are allowed to hold null, and which aren't." -- false.
Sep
26
comment Ordered enumeration: IEnumerable or Array (in C#)?
@StevenJeuris Your question wouldn't be necessary if C# were properly designed and had an ISortedCollection<T> interface, which you would extend if you needed the collection to be sorted. But since it doesn't, the only way to prevent misuse at compile time is to either extend an overly narrow type (IList<T>) or to extend IEnumerable<T> and do an unnecessary sort.
Aug
30
comment Why is DRY important?
"Strongly depends if doStuffX depends on each other or not." -- DRY has nothing to do with whether they depend on each other, but rather whether they duplicate decisions.