Inappropriate Type Checking

(Based on WhatsaControllerAnyway)

That's perhaps lack of dynamism in the language or GUI kit. Type-heavy systems which do not support abstract interface definitions make it harder to polymorphically swap the underlying widget. True, type-heavy systems don't have to be that way (catch that Lars?), but it seems the designers often don't take care to maintain swappability in that environment.

For example, for a check-box, a kit may require you use a "checkBoxHandler" class to handle its events. But if we swap the checkbox for a toggle icon, then our "checkBoxHandler" has to also be changed to a "toggleIconHandler". Proper ModelViewController architecture, regardless of static versus dynamic typing, doesn't do this. It's almost a case of using duplication of information (An X-handler can only go to X-widget-type) for a kind of type "matching guarantee" safety. It's the darker-side of protection-orientation when in the wrong hands.

A dynamic kit would only care that the handler have the expected methods, and thus conforms to a uniform dynamic type, and does not care what the actual class is.

--top (italics not mine)

I have to wonder what kind of "type-heavy" systems you've used, because in my experience, none of what you discuss above has ever held true for me.

[Indeed. Top, beware of using one example of a poorly-designed class hierarchy to fallaciously make a general case against "type-heavy" systems. Obviously, if the check-box and toggle icon can both be based on the same model, it only makes sense to employ a "toggleHandler" for both. Bad libraries can be implemented using any paradigm, thus these should never be the foundation for general arguments.]

I thought I made it fairly clear that it was a bad practice rather than an inherent fault of heavy-typing. More accurately, I'm saying that a heavy-typing mentality tends to lead to such designs. I'm making a statement about human tendencies under circumstances, not absolute statements about a technology itself. --top
[I'm afraid that wasn't clear at all.]

There are certain rigid languages (a property not entirely orthogonal to 'type-heaviness', but more associated with flexibility requiring extra effort and syntax) where DoTheSimplestThingThatCouldPossiblyWork very rarely leads to a highly flexible, polymorphic frameworks and libraries. This includes frameworks for GUI operations and widgets and whatnot. Such flexibility would be obtained after 'globally' applying RefactorMercilessly over the issues encountered after the framework has been applied in a wide variety of different projects, but such refactoring is very rarely possible to do due to compatibility issues and the refactorer not having access/modify rights to everyone else's projects. I've certainly ran face-first into rigid framework-erected walls before where something more dynamic, like language-supported DuckTyping, would have allowed me to maneuver, weave, and 'duck' problems to get done what I needed done.

So I can see where Top is coming from, though his tendency to dump all sorts of vaguely correlated problems (like 'rigidity') in the lap of 'type-checking' still irks me to no end. It's almost as though he's just looking for things to blame on type checking, and unwilling to give it more thought after it strikes him as a negative. If he were fair, he'd be more careful: he certainly gets defensive when people mention correlations against 'procedural' as though the problem is even remotely 'caused by' being procedural (e.g. "many procedural languages lack linguistic support for encapsulation or modular design").

Some people do value explicitness over flexibility in order to reduce (perceived or forecasted) accidental mismatches. It is "protectionism" gone wrong. My pet technologies can also be abused, I'll perfectly admit that. Look at it as a warning for those trying to achieve "protection" (in a misguided way). Be they reminded not to trade flexibility in the process. -- top

As far as "protectionism gone wrong" - I imagine that most of the time it isn't "protectionism" that prevents flexibility. It's laziness, YagNi... DoSimpleThings applied in a language where simple things are 'rigid' and flexible solutions require effort that you can't demonstrate You Gonna Need (which really hurts for shared frameworks and libraries because someone else will 'need it' even if you don't). I'll readily admit to preferring type systems that don't interfere with flexibility. That is, I prefer languages where the structure required by the type description isn't very 'rigid' unless more effort goes into describing said type - flexibility by default, take it away by greater effort, allowing 'flexibility' to follow from 'laziness' and 'rigidity' to follow from demonstrating that you do, indeed, 'need it'. Compare CeePlusPlus - it's the complete opposite, requiring explicit additions of the 'virtual' keyword, rejecting subtypes of a class where an object of a particular class is required (without 'explicit' use of pointer or reference), doesn't support getter/setter methods to overload class attributes, doesn't support overloading class attributes at all, doesn't allow you to create another class that matches the interface of the first and automatically use it (without explicit templated polymorphism). Not that CeePlusPlus is "protectionist", it's just got a big load of (arguably) PrematureOptimization on its plate.

If you want to create a page called "misuse of table-oriented-programming" or the like, be my guest. (I suspect some of you will avoid that to risk appearing to legitimize T.O.P.) --top

I have no issues at all with programming languages supporting FirstClass relations (or AdaptiveCollections), queries, and even micro-databases (essentially records of relations) for various purposes in some variation of TableOrientedProgramming (though your particular brand of it, with TQL and all that, doesn't interest me). Of course, I would like any such features to support arbitrary structured values consistent with the rest of the language rather than your favored approach of 'protecting' everyone from the user by limiting it to numbers, dates, and strings (if not just strings... you've got so many inconsistent views about 'protectionism'...).

I hope this doesn't involve the Catholic Church somehow.