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

37m
comment Should a class know about its subclasses?
@JohnGaughan: If some derived types offer a way of doing something that's better than any means available via the base type, how could code hope to exploit such a feature on objects that support it, but also accept objects without it, other than by testing whether an object it receives is an instance of a type that supports the feature? If the feature doesn't exist in the base class, there won't be anything for a derived class to override.
2h
comment Programming for future use of interfaces
...the parameter should do something. It may be reasonable for implementations to allow filtering by end date even if that ability isn't needed at the moment, but it sounds as though implementations aren't expected to do that. That would seem dubious to me. BTW, something like end seems like something implementations should honor. Even if data could be filtered downstream, why encourage the system to fetch data that's never going to be used? If code doesn't want anything after July 9, the information-retrieval code should know that.
2h
comment Programming for future use of interfaces
...it's a very bad idea for methods in an interface to include parameters whose meaning is undefined. In the callback scenario, the parameters have meaning to the middle layer--what's received from the outer layer is the thing the outer layer wants the inner layer to have, and what's given to the inner layer is the thing the outer layer wants it to receive. The middle layer might not know anything beyond that, but it doesn't need to--those specifications would make clear what the middle layer should do with the parameter. In your scenario, the name "end" implies that...
2h
comment Programming for future use of interfaces
There are times when it makes sense for interfaces to contain parameters for "future expansion", particularly in scenarios involving callbacks. For example, if a collection includes a "invoke some interface method on all items" method, it may be useful for such a method to include a parameter which it simply passes along to the interface method which it calls. Even if there's no particular expectation of how that parameter would be used, it's better to have such a thing than try to retrofit code to deal with it or muck about with ThreadLocal storage. On the other hand...
6h
comment Is it a good idea to return a default value if a field in a query cannot be found?
...I was actually thinking of an overload which simply specifies a default value. For example, in a free-form database, SpecialAbilities = Customer.GetAttributeOrDefault("Specials", SpecialAbilities.None); Note that GetFieldOrDefault should return the default value if it found that the customer was seemingly valid but did not have that attribute set; it should throw an exception if there was a problem reading customer data.
6h
comment Is it a good idea to return a default value if a field in a query cannot be found?
@JohnR.Strohm: A well-designed API should seldom require a method to be invoked within its own try/catch block. If a method would be called by code that's prepared to handle a condition, there should be a form of the method where that condition does not cause an exception. If many callers to a method would respond to a particular condition the same way, having a version of the method which incorporates that handling internally is better than requiring duplicate code at every call site. BTW, while an overload that accepts a Func<T> to generate a default value is a good thing to have...
22h
comment Is it a good idea to return a default value if a field in a query cannot be found?
I would suggest that it's often helpful and safe to have a "get something or return a caller-supplied default method if there is also a "get something or throw exception" fallback. If the caller has to supply the default, the called method should have no problem knowing a "safe" default for the context in which it is called.
22h
comment Should a class know about its subclasses?
@JohnGaughan: The fact that a base class can be used to perform some operation X using a particular sequence of method calls, and a derived class can be used in the same way, in no way implies that a derived class might not also have a much better means of doing X which is not available in the base. For example, calling Count on a reference of type IEnumerable<int> which happens to identify an int[100000000] could iterate through one hundred million items, but calling ICollection<int>.Count will be much faster.
22h
comment Why can't C arrays have 0 length?
@KevinCox: Not only that, but a pointer to the element past the end of e.g. an array of int would be valid only in that sense.
22h
comment Why can't C arrays have 0 length?
@RobertHarvey: Given struct { int p[1],q[1]; } foo; int *pp = p+1;, pp would be a legitimate pointer, but *pp would not have a unique address. Why could the same logic not hold with a zero-length array? Say that given int q[0]; within a structure, q would refer to an address whose validity would be like that of the p+1 example above.
1d
comment Is it fine to make a default constructor unusable?
@Doval: Using separate constructors, one could simply say that as part of the inheritance contract, that the outermost constructor is required to call a protected sealed ConstructionComplete method, which would then finish construction within a try/catch block that would ensure proper cleanup if anything went wrong.
1d
comment Is it fine to make a default constructor unusable?
@Doval: I wish that instead of Finalize(), .NET had included a protected ManageLifetime method with a parameter indicating various kinds of things that needed to happen, and would have called such a method with a ConstructionComplete action between the call the outermost constructor and the return to calling code, and with a ConstructionFailed action if a constructor failed due to an exception. That would have allowed such event-attachment scenarios to be handled much more cleanly. No such thing exists, though, so using separate constructors is the best alternative I can see.
1d
comment Is it fine to make a default constructor unusable?
@Doval: A class whose purpose is to attach itself to another object and receive events therefrom should perform such attachment only after all other instance construction is complete. If one is constructing a base-class instance, the base-class constructor itself needs to perform such attachment because nothing else is going to do it. If one is constructing a derived-class instance, however, the base-class constructor should not perform such attachment but should leave the job to the derived-class constructor.
1d
comment Why is there no deterministic object destruction in Java?
@JanHudec: An expressive language should distinguish between references that encapsulate things that are "owned" by the owner of the reference, those that encapsulate unowned immutable objects, and references that encapsulate identity. Managing ownership is critical for types that encapsulate resources, but not really any less critical for types that encapsulate mutable state. If a language distinguishes distinguishes the different kinds of references, managing resources shouldn't be hard. A language can't manage resources, though, without knowing who owns them.
1d
comment Is it fine to make a default constructor unusable?
If a particular constructor should be usable only for creating base-class instances, but not for creating derived-class instances, would there be any way to enforce that other than by throwing an exception if this.GetType() != typeof(myType)?
1d
comment Is catching general exceptions really a bad thing?
@Magus: It can throw all sorts of exceptions--that's the problem. It's often very difficult to anticipate all the kinds of exceptions that might get thrown as a consequence of invalid data in a file. If one doesn't use PokeMon handling, one risks having an application die because e.g. the file one was loading contained an exceptionally-long string of digits in a place which required a decimal-formatted 32-bit integer, and a numerical overflow occurred in the parsing logic.
2d
comment In Java, what are checked exceptions good for?
In any polymorphic language, there are going to be cases where some implementations of an abstract method will throw certain exceptions and other ones won't. There will also be cases where code will have good reason to believe that the implementations it is using are ones that will never throw. A good language should provide a concise means of saying "I am not expecting this method to throw any exceptions; any exceptions it does throw should be considered 'unexpected'", without requiring code to pretend to handle exceptions it can't deal with.
2d
comment In Java, what are checked exceptions good for?
@owlstead: Checked exceptions should only bubble through intermediate layers of the call stack if they are thrown in cases that the intermediate calling code expects. IMHO, checked exceptions would have been a good thing if callers had to either catch them or indicate whether or not they were expected; unexpected exceptions should be automatically wrapped in an UnexpectedException type derived from RuntimeException. Note that "throws" and "doesn't expect" are not contradictory; if foo throws BozException and calls bar, that doesn't mean it expects bar to throw BozException.
2d
comment Is catching general exceptions really a bad thing?
@Magus: With a method like LoadDocument(), it's essentially impossible to identify all the things that might go wrong, but 99% of exceptions that could be thrown will simply mean "It was not possible to interpret the contents of a file with the given name as a document; deal with it." If someone tries to open something that isn't a valid document file, that shouldn't crash the application and kill any other open documents. Pokemon error handling in such cases is ugly, but I don't know any good alternatives.
2d
comment Workaround for Java checked exceptions
@duros: Depending upon why the exception "can't happen", the fact that it gets thrown may indicate that something is severely wrong. Suppose, for example, if one calls clone on a sealed type Foo which is known to support it, and it throws CloneNotSupportedException. How could that happen unless the code got linked with some other unexpected kind of Foo? And if that happens, can anything be trusted?