I'm proposing that we use encapsulation and possibly ADTs to define clear boundaries for functionality in the code base. Rather than have one massive code base, I'd like to see subsystems that can be worked on internally with minimal effect to the users of that subsystem. OpenOCD has some of that and Zach has been doing a lot of work to refine that.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned On Jun 9, 2009, at 8:51 PM, David Brownell wrote:
On Tuesday 09 June 2009, Rick Altherr wrote:although this is the first time I've ever heard anyone apply that term to C. ...I've commonly heard C and C++ referred to as strongly-typed.Never *once* have I heard that usage before yours. Usually C gets described as a weakly/loosely typed language. (This is in the context of multiple classes and seminars that did comparative studies of dozens of programming languages and type systems.)The fact that you can't declare a variable without a type is an indication of this.No; it just means they have types, and require declarations. But in fact, C doesn't require, and never has required, types for everything. I just compiled the following; no errors, and not even any warnings unless I specify "-std=c99". main(argc, argv) { argc = argv; return 0; } Over time, C has integrated mechanisms that lets one's code trigger warnings from some flavors of type abuse. But at its core, it's still weakly typed. Plus, having a declaration says nothing about whether that will be "strongly" enforced, or can instead be suborned.void * let's you work around some undesirable effects of strong- typing, but it is a type itself.That "work around" means "violate any type rules you want", which is prima facie evidence that the type system is not what's called "strong" ... either at compile time, or at run time. Contrast that to something like LISP or Lua ... or even TCL. In key ways, those have stronger typing than C: they have only a handful of data types and you can't escape them. (That property is also a flavor of what's called "safety", and one which lends itself to crash-free software. C is not known for being crash-free; neither is C++.) But on the flip side their type systems are not extensible, so when you build abstraction layers you've got to define your own typing conventions. Which can't be enforced at compile time (another aspect of "safety", which would help some other robustness characteristics), so they're weak in those respects. Yet C provides some extension mechanisms... :)However, I'm all in favor of evolving code to respect clearly defineddata types, which encapsulate roles and responsibilities to supportbetter system structures. If there's a better way to do it, I've notyet come across that answer. :)That's really all I'm recommending. I've seen a dynamic- and strongly-typed language do very well for doing encapsulation and using ADTs to make a very clean system architecture that allows for lots of future extensions.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development