Re: [Openocd-development] RFC: struct cleanup and more

[Rick Altherr]

On Jun 9, 2009, at 6:41 PM, David Brownell wrote:

On Monday 01 June 2009, Rick Altherr wrote:

C and C++ are both strongly typed

break out of the type system.

I'm used to definitions of "strong" typing that preclude the inability to

That would be "very strong". "strong" just means that a variable has a designated type associated with it. "weak" on the other hand is like JavaScript where a variable has no type information attached to it.

C makes that trivial:  cast to/from "void *"
pointers, and you're done.  That's because it was intended from the

hide the machine-specific details that "strong" typing does.

start to be a low level language, for systems programming, which doesn't

"strong" typing has nothing to do with hiding machine-specific details. It's all about a variable being designated to hold a specific type of data rather than an arbitrary type. Now, void * in C lets you cast between types that would otherwise cause errors. That doesn't make it "weak", just not as "strong".

It is however worth pointing out that there are dozens of definitions

heard anyone apply that term to C.  (Since I first found a looseleaf
binder of line-printer output, called "The C Programming Language", in

very available!)

of what "strong typing" is ... although this is the first time I've ever one of the libraries at Case Western. The printed/bound versions weren't

I've commonly heard C and C++ referred to as strongly-typed. The fact that you can't declare a variable without a type is an indication of this. void * let's you work around some undesirable effects of strong- typing, but it is a type itself.

C++ adds a few type frameworks to C, yes, but still doesn't have what I'd

call "strong" typing.  (Plus, all its dynamic/reinterpret/static/const
cast mechanisms get confusing.)

I agree the multitude of options for casting are confusing in C++, but those actually point to the fact that C++ is strongly typed by default. The reason that dynamic_cast exists is that C++ assumes that references to variables are to a specific type (static typing) and will normally write code to access it directly as such. dynamic_cast tells C++ to instead evaluate the type at runtime (dynamic typing) so the underlying type can be changed without recompiling the calling code.

         but proper use
of an abstract type can greatly simplify the implementation as the

efforts to simplify the target APIs has shown. We are already adopting most of the encapsulation paradigm for targets and ADTs build on that.

Encapsulation != strong typing (and vice versa!).

I never said it was. Encapsulation can easily be done in any language regardless of strong vs weak. ADTs on the other hand build on top of encapsulation and dynamic runtime type information. They utilize encapsulation to hide the internal details of the object so that those internals can be changed by subclasses. Further, by using dynamic typing, the subclasses can be passed a reference to the ADT and convert it into their subclass so they can do special things to it.

And I still stand
by my observation that I've usually seen *team* approaches to strong
typing fail, when they need to be built with weakly typed languages.
The dynamics rarely support it as the code base evolves.

I'm not a huge fan of "very strong" for typing nor of static typing. They purport to improve the stability of the code by always knowing what can be done with an object but it makes for a lot of nasty code though since non-trivial programs often need some of the features of weak-typing along with dynamic typing. I'm actually quite fond of Objective-C which is strongly-typed and very dynamic. Further, everything is allocated on the heap and passed by pointer. So objects can be cast to a generic type that means "some type of class" and then have the type information recovered by asking the object.

However, I'm all in favor of evolving code to respect clearly defined
data types, which encapsulate roles and responsibilities to support
better system structures.  If there's a better way to do it, I've not
yet 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.

I think that a well thought out implementation of an abstract target
type and interface will do wonders to the code base and maintenance.
Using encapsulation will make this even better for future expansion
and enhancement.

All that's true, but it's still very different from "strong typing"
(using any definition I've worked with).

:)

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development