3,549 reputation
514
bio website
location Illinois
age 45
visits member for 2 years, 10 months
seen 2 days ago

2d
comment while(true) and loop-breaking - anti-pattern?
@LorenPechtel: That structure goes back a long time [not sure about Cassette Basic, and I don't have an original PC to test it with, but certainly to QuickBasic if not before], and QuickBasic was hardly a wonderful language. It may not be as nice as the looping in Ada, but at least it was designed for mid-exit looping.
2d
comment Why is the 'out' keyword used in two seemingly disparate contexts?
The way to remember co- versus contra-variance is to consider what happens if a function in an interface takes a parameter of of an generic interface type. If one has an interface Accepter<in T> { void Accept(T it);};, an Accepter<Foo<T>> will accept T as an input parameter if Foo<T> accepts it as an output parameter, and vice versa. Thus, contra-variance. By contrast, interface ISupplier<out T> { T get();}; a Supplier<Foo<T>> will have whatever sort of variance Foo has--thus co-variance.
2d
comment Why do most programming languages have special keyword or syntax for declaring functions?
@JanHudec: Semantically, Java has both functions and methods; it uses the terminology "static methods" when referring to functions, but such terminology doesn't erase the semantic distinction.
2d
comment return Trivial booleans?
@Izkata: Exceptions may not cost much from a performance standpoint, but they can still make some "repeat until success or failure count exceeded" loops awkward.
2d
comment while(true) and loop-breaking - anti-pattern?
I like your point about emulating missing control structures with control structures. That's probably a good answer to GOTO-related questions as well. One should use a language's control structures whenever they fit semantic requirements, but if an algorithm requires something else one should use the control structure required by the algorithm.
2d
comment while(true) and loop-breaking - anti-pattern?
@LorenPechtel: VB.NET, as well as many preceding dialects (I believe dating all the way back to Cassette Basic) included "Do ... Loop" [with neither end of the loop supply a condition], and allowed code within the loop to "If XXX Then Exit Do". That seems a little cleaner than C and offshoots which require a dummy condition at the start or end of the loop.
2d
comment Short circuit evaluation, is it bad practice?
If one has try methods that return true in case of success, what do you think of if (TryThis || TryThat) { success } else { failure }? It's a less commmon idiom, but I don't know how to accomplish the same thing without code duplication or adding a flag. While the memory required for a flag would be a non-issue, from an analysis standpoint, adding a flag effectively splits code into two parallel universes--one containing statements that are reachable when the flag is true and the other one statements reachable when it's false. Sometimes good from a DRY perspective, but icky.
May
18
comment Why is negative zero important?
I wish IEEE-754 had included four zeroes: "exact", positive infinitesimal, negative infinitesimal, and unsigned (the latter being the difference between indistinguishable values). Doing that would have made a lot of floating-point axioms work--among them, x+0.0 equiv x-0.0 equiv x, x-y equiv x+(-1.0)*y, and 1.0/x equiv -1.0/(-1.0*x) [if x is positive zero, both would be pos-inf; if neg-zero, both neg-inf; if exact or unsigned, both NaN].
May
18
comment Code maintenance: keeping a bad pattern when extending new code for being consistent, or not?
@StevenJeuris: Coincidentally-matching behavior shouldn't be considered "common" behavior. Only if one knew that any future changes to one behavior should also affect the other should one be eager to factor out common code; if there's any possibility of changes to one that shouldn't affect the other, one should be reluctant.
May
18
comment Code maintenance: keeping a bad pattern when extending new code for being consistent, or not?
...adding the additional behavior to locker banks will be easy if locker banks and button banks have distinct getRow methods, but may be more difficult if the functions have been merged to a common method.
May
18
comment Code maintenance: keeping a bad pattern when extending new code for being consistent, or not?
Refactoring which removes duplicated code is not always good; it's possible that two methods might be identical under today's business rules, but that not tomorrow's. For example, an AcmeLockerBank one might have a getRow(int itemIndex) method which returns index % 5 and an AcmeButtonPanel might have an identical method because both the locker and button boards number things the same way; if none of today's locker banks have items with an index over 1000 but some button panels do, and future lockers use a different row spacing for indices in the 1000-1999 range...
May
14
comment Do Programmers sometimes intentionally over complicate code?
...it would have greatly eased promotion/balancing rules. A non-promotable unsigned short added to a promotable int would yield a non-promotable unsigned short, whether or not short is as large as int. A promotable unsigned short added to a promotable int would yield an int. Adding signed and unsigned things of the same size, or adding non-promotable things of different sizes, would be an error. Add a tiny bit of complexity up front, and weird corner cases downstream disappear.
May
14
comment Do Programmers sometimes intentionally over complicate code?
It's amazing how many systems start out with a really simple core which almost fits requirement but falls short in many distinct ways, and then end up adding lots of complications to deal with lots of gaps which could have been avoided with a slightly more complicated design. Consider the simple design of C's integer types and some of the bizarrely-complex rules that go with them. If for each type there had been a "should this be promotable" option, that would have nominally doubled the number of types (though not really in a way different from a qualifier like volatile, etc.) but...
May
13
comment Is there a real advantage to dynamic languages?
...references to types that implement the interface directly, or references to types with auto-generated implementations. This would achieve many of the advantages of dynamic typing, but without the semantic free-for-all of making every object behave as a Map<String,Object>.
May
13
comment Is there a real advantage to dynamic languages?
+1 There are some situations where the necessary semantics aren't really a good fit for the type relationships available in statically-typed languages, but the proper remedy shouldn't be to throw all the useful aspects of static typing out the window. Rather, what's needed IMHO is a means by which an interface could deem itself to be implemented by any class meeting certain criteria [the system should auto-generate method implementations which chain to static methods designated by the interface]. Consumers of the interface would then not have to worry about whether they are receiving...
May
8
comment What's the idea behind naming classes with “Info” suffix, for example: “SomeClass” and “SomeClassInfo”?
@NathanTuggy: I find that surprising. Do the properties getters of FileInfo go out to disk, or what? That would seem contrary to normal property-getter behavior, and could cause problems if a USB drive disappears.
May
8
comment What's the idea behind naming classes with “Info” suffix, for example: “SomeClass” and “SomeClassInfo”?
@NathanTuggy: Calling Refresh would make the FileInfo object's state indicate the state of the file at the time Refresh was called. Would modification or deletion of the file affect a FileInfo if Refresh were never called on it?
May
8
comment What's the idea behind naming classes with “Info” suffix, for example: “SomeClass” and “SomeClassInfo”?
@NathanTuggy: I didn't remember the exact particulars of the classes in question, but I thought FileInfo just held statically-captured information. Does it not? Also, I've never had occasion to open files in non-exclusive mode, but it should be possible, and I would expect there to exist a method that will report a file's current size, even if the object used for opening isn't called File (normally I just use ReadAllBytes, WriteAllBytes, ReadAllText, WriteAllText, etc.).
May
8
comment What's the idea behind naming classes with “Info” suffix, for example: “SomeClass” and “SomeClassInfo”?
@NathanTuggy: I would not recommend using .NET as a model of any sort of consistency. It's a good and useful Framework that encapsulates a lot of good ideas, but a few bad ideas get captured in the mix as well.
May
8
comment Why are structs and classes separate concepts in C#?
@LokiAstari: I think it could be made less argumentative, but without loss of meaning, if "is a horrendous mess" were replaced with with "has led to many difficulties and complications which the creators of .NET did not wish to repeat". I don't think any even the most ardent C++ supporter would claim that the C++ approach doesn't lead to many difficulties, nor would .NET advocates claim that the C++ approach has no advantages whatsoever. The only point of contention is the relative magnitude of the problems and advantages.