🚀 go-pugleaf

cookd@cs.byu.edu wrote 10.01.96 on Re: whither style:

> On 8 Jan 1996, Joachim Durchholz wrote:
>
> > I think HN is inappropriate for languages where you can change the
> > representation of a type behind the scenes, simply because it's impossible
> > to invent an abbreviation for every type that shows up in a project.
>
> In a way, you almost have it exactly right here, but it isn't the language
> that is the deciding factor--it is the environment of the language.  When
> you run your programs in an environment where you must pass information
> from one program to another, type checking is not applicable so a
> notation is necessary to remind programmers (especially when they are
> doing low-level stuff as is often necessary when moving data between two
> programs) what type they should be using.

Good point.
But still:

> When I call the Windows API,
> it is nice to see that the variable name is lpsz.... when the type is a
> generic POINTER that could point to anything.

But shouldn't the Windows API prototype be declared with something more  
specific than a POINTER? This sounds more like a problem how careful the  
API designer is. If the predefined APIs aren't specific enough, nobody  
will hinder you to define a more specific interface.

> When I save data in a file
> that could be read by an Intel based implementation of Modula II or
> Pascal, a MIPS version of C, or an embedded system running code developed
> in Ada, it is nice to know that they all expect an i16... (or however the
> notation says int16 should be prefixed).

This could be handled by taking care that all language-specific parts of  
the API are consistent.


Of course keeping the interfaces consistent across vastly different  
languages needs a bit of thinking. But I should be able to handle this by  
doing stuff in some simple, easy-to-parse language and can automatically  
translate to other languages, so it's not really an issue.

-Joachim

--
Im speaking for myself here.
## CrossPoint v3.02 ##