1,536 reputation
39
bio website
location Illinois
age 44
visits member for 2 years
seen 2 hours ago

Jun
19
comment Demonstration of garbage collection being faster than manual memory management
@ddyer: Actually, GC and scope-based resource management should complement each other nicely; I find it rather unfortunate that languages don't try to combine the benefits of both.
Jun
19
comment Why was C# made with “new” and “virtual+override” keywords unlike Java?
IMHO, while there are definitely uses for having functions non-virtual, the risk of unexpected pitfalls occurs when a something which isn't expected to override a base-class method or implement an interface, does so.
Jun
18
comment How to avoid downcasting?
@Giorgio: I should add that I very much like virtual dispatch; in cases where base types include the methods which are needed on derived types, virtual dispatch may avoid the need for downcasting. On the other hand, the Interface Segregation Principle argues that base classes and interfaces should avoid defining methods which aren't applicable to all derived classes. Personally I think that rule is often taken too far, with some rather unfortunate consequences, but unless one throws that rule totally out the window downcasting will often be unavoidable.
Jun
18
comment How to avoid downcasting?
@Giorgio: I would call that "virtual" rather than dynamic. As I would expect the terms to be used, dynamic dispatching entails searching for a suitable function, while virtual dispatch entails invocation of a function whose entry point is stored in a known location. If the hidden information associated with Java objects were stored as fields, a call like someObject.equals(other) would be equivalent to something like someObject.typeInfo.methods[INDEX_OF_EQUALS](someObject, other);.
Jun
18
comment How to avoid downcasting?
@Giorgio: Perhaps I was confused by the code in your comment; I don't know of any virtual method equalToString as part of Object, so what were you intending there?
Jun
18
comment Why was C# made with “new” and “virtual+override” keywords unlike Java?
@svick: What would you think of defining a new function but tagging it Obsolete("Use XX or YY depending upon requirements", true) and refactoring code which expects the derived-class meaning to use a slightly-renamed alternative? That should avoid hidden bugs.
Jun
18
comment Why was C# made with “new” and “virtual+override” keywords unlike Java?
@C.Champagne: I meant GrafDerived. I started out using DerivedGraphics, but felt it was a bit long. Even GrafDerived is still a bit long, but didn't know how best to name graphics-renderer types which should have a clear base/derived relation.
Jun
18
revised Why was C# made with “new” and “virtual+override” keywords unlike Java?
Split wall of text
Jun
18
comment Are error variables an anti-pattern or good design?
...but having an object class to hold information about problems may be more helpful than throwing exceptions or returning a pass-fail error code. It would be up to the application to use that information in suitable fashion (e.g. when loading file "Foo", inform the user that data may not be reliable, and prompt the user to choose a new name when saving).
Jun
18
comment Are error variables an anti-pattern or good design?
@jhr: When is there ever any guarantee of anything? The contract for a class may specify that clients have certain responsibilities; if clients abide by the contract, they will do the things the contract requires. If they don't, any consequences will be the fault of the client code. If one wants to guard against accidental mistakes by the client and has control over the type returned by a serializing method, one could have it include an "unacknowledged possible corruption" flag and not allow clients to read data from it without calling an AcknowledgePossibleCorruption method...
Jun
18
revised Why was C# made with “new” and “virtual+override” keywords unlike Java?
Corrected `DerivedGraphics` to `GrafDerived`.
Jun
18
comment Why is there usually a reference to Java when when people talk about C#?
@Giorgio: Unfortunately many ideas which may have been okay in the absence of value types (e.g. the merging of . and ->, or use of == for both value and reference comparisons) were brought in from Java without regard for whether they would play nicely with value types.
Jun
18
answered Why was C# made with “new” and “virtual+override” keywords unlike Java?
Jun
18
comment Apply filter only if not null
The issue isn't just when there are lots of combinations. Even when there are just two options, I would consider avoidable code duplication smelly. Consider, for example, [Try]ParseRecord. If throw-on-error is controlled by a parameter which can be passed to [Try]ParseSubRecord, then subrecord parsing can throw an exception which the main caller will be able to see. If the methods are completely separate, then all the code will have to be duplicated, creating a significant possibility that the two methods may end up unintentionally differing in what they accept.
Jun
18
comment How to avoid downcasting?
@BryanChen: That depends on your terminology. I don't think Object has any equalStoString virtual method, and I'll admit I don't know how the quoted example would even work in Java, but in C#, dynamic dispatch (as distinct from virtual dispatch) would mean that the compiler essentially has to do Reflection-based name lookup the first time a method is used on a class, which is distinct from virtual dispatch (which simply makes a call via a slot in the virtual method table which is required to contain a valid method address).
Jun
17
comment Apply filter only if not null
An advantage of using parameters to select choices, which is lost by using distinct functions, is that a single wrapper which passes caller-supplied options to a wrapped method can handle many different usage cases. If the different usage cases were segregated into different methods, it would be necessary to create a separate wrapper for each.
Jun
17
comment How to avoid downcasting?
@Giorgio: Dynamic dispatching has its uses, but it's generally even worse than downcasting.
Jun
17
answered How to avoid downcasting?
Jun
14
answered Why do arrays in Java not override equals()?
Jun
14
comment Why do arrays in Java not override equals()?
Arrays are real objects. The fact that they are the only multi-element aggregate type means any other forms variable-sized collection must be backed by either arrays or else O(N) objects outside itself, so by comparison arrays will be "lightweight". I think the more fundamental issue is not that arrays are lightweight, but rather that there are so many ways of using them. See my answer below.