3 ms·

This is a non-issue in C#. In C#, properties have getters and setters. Instead of making a function named GetPrice() you'd simply modify the price getter to inc

by dimgl 11y ago

This is a non-issue in C#. In C#, properties have getters and setters. Instead of making a function named GetPrice() you'd simply modify the price getter to include the additional fees.

bunderbunder 11y ago
You've pointed out a distinction without a difference. On the back end C# properties are implemented as a pair of CLR methods named get_[PropertyName]() and set_[PropertyName](). The rest is syntactic sugar. So when you "simply modify the price getter", what you're doing is simply modifying the implementation of a method named get_Price().
- dimgl 11y ago
  Right, but the article is arguing the inconvenience of having to make such methods across all classes that derive from a superclass. If this is inherently provided in the language then I would say that language doesn't suffer from the issue discussed in this article. And that language I'm speaking of is C#.
  - manyxcxi 11y ago
    With respect to Java, the getters and setters are automatically generated in an IDE if you want, so it's not all so bad. And if you get to a spot where your getter and setter needs to do more than spit out the value or assign it for some reason, you're really at the same amount of code. It is definitely nice in C# not having to LOOK at all the damn getters and setter though.
jfoutz 11y ago
It's not so much about that specific case, any other side effect will get you in trouble. it's more about how 'extends' introduces 2 tricky features. 1) you get a neat dispatch mechanism. if foo doesn't have a method check foo's superclass, and see what's available there, recursively until you run out of parents. 2) you can slip a different implementation in to some complex system, and they never need to know. A nice example might be a DatabaseConnection, and a TestDatabaseConnection, that doesn't actually talk to a database, but logs what was requested. The thing that sucks about inheritance is, you never really have a DatabaseConnection, you wind up having a MYSQLDatabaseConnection or a PGSQLDatabaseConnection, that take slightly different syntax. It's not real clear if you should make a TestDatabaseConnection for each database permutation, or just make a logging connection. Anyway, traits can fix this up a little nicer than interfaces and delegates can. Inheritance is helpful, but it kind of sucks because you only get to use it once, and it mixes two different concepts together. "easy" API extension by tacking on more features, and the cuckoo's egg that lets you slip different implementations in without a recompile. IMHO #2 is really what people are after, and you can get that by just using interfaces for everything.

by dimgl 11y ago

This is a non-issue in C#. In C#, properties have getters and setters. Instead of making a function named GetPrice() you'd simply modify the price getter to include the additional fees.

bunderbunder 11y ago

You've pointed out a distinction without a difference. On the back end C# properties are implemented as a pair of CLR methods named get_[PropertyName]() and set_[PropertyName](). The rest is syntactic sugar. So when you "simply modify the price getter", what you're doing is simply modifying the implementation of a method named get_Price().

dimgl 11y ago
Right, but the article is arguing the inconvenience of having to make such methods across all classes that derive from a superclass. If this is inherently provided in the language then I would say that language doesn't suffer from the issue discussed in this article. And that language I'm speaking of is C#.
- manyxcxi 11y ago
  With respect to Java, the getters and setters are automatically generated in an IDE if you want, so it's not all so bad. And if you get to a spot where your getter and setter needs to do more than spit out the value or assign it for some reason, you're really at the same amount of code. It is definitely nice in C# not having to LOOK at all the damn getters and setter though.

jfoutz 11y ago

It's not so much about that specific case, any other side effect will get you in trouble. it's more about how 'extends' introduces 2 tricky features. 1) you get a neat dispatch mechanism. if foo doesn't have a method check foo's superclass, and see what's available there, recursively until you run out of parents. 2) you can slip a different implementation in to some complex system, and they never need to know. A nice example might be a DatabaseConnection, and a TestDatabaseConnection, that doesn't actually talk to a database, but logs what was requested. The thing that sucks about inheritance is, you never really have a DatabaseConnection, you wind up having a MYSQLDatabaseConnection or a PGSQLDatabaseConnection, that take slightly different syntax. It's not real clear if you should make a TestDatabaseConnection for each database permutation, or just make a logging connection. Anyway, traits can fix this up a little nicer than interfaces and delegates can. Inheritance is helpful, but it kind of sucks because you only get to use it once, and it mixes two different concepts together. "easy" API extension by tacking on more features, and the cuckoo's egg that lets you slip different implementations in without a recompile. IMHO #2 is really what people are after, and you can get that by just using interfaces for everything.