Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!ginosko!uunet!microsoft!paulkle
From: paulkle@microsoft.UUCP (Paul Klemond)
Newsgroups: comp.software-eng
Subject: Re: Experiences with Hungarian Nami
Message-ID: <7545@microsoft.UUCP>
Date: 28 Aug 89 20:54:20 GMT
References: <489@fdmetd.uucp> <138300001@cdp>
Reply-To: paulkle@microsoft.UUCP (Paul Klemond)
Organization: Microsoft Corp., Redmond WA
Lines: 77

In article <138300001@cdp> jeff@cdp.UUCP writes:
>
>Hungarian notation is being promoted by the Microsoft folks as the
>best thing since sliced bread.  But there's a sad (funny?) side
>to this: Hungarian notation flies in the face of what we've been
>trying to teach and practice for years with the notions of information
>hiding and abstraction.  Hungarian notation encodes the type of each
>primitive data object into the name of the object.  The loss of
>abstraction should be obvious: for example, changing the underlying
>implementation of a variable requires that its name also be changed.
>
>I'm not familiar with the environment at Microsoft -- it's conceivable
>that this is truly one step forward for them -- but for many of us,
>it's one big step backwards.


I brought this view to the attention of Charles Simonyi, the "inventor"
or hungarian notation (Charles is Hungarian, thus the notation's name).
Here's what I said to him:

Above is someone's critical view of Hungarian. I see points for both sides:

  1.  The "reality" of doing competitve (high-performance) programs
      forces us to use the environments we do, the limitations of
      which we must live with.  Hungarian is of benefit to us in
      these more practical, more competitive environments.

  2.  A fundamental change in our environments, one we should make,
      renders Hungarian substantially less useful.


Here's his reply:

the point is clever, but was probably made after contemplation rather
than practice. Hungarian in fact helps abstraction in the following
way: primitive tags (such as ww for window numbers) represent the
abstraction itself rather than the underlying representation (which
would be int, char, or long in this case, maybe encoded into a typedef
called WW. So in this case Hungarian is more modern than using just 
the "int" type and some random name. CloseWw(ww), for example, is
really an operation Close on the type ww.

What the msg. is proably referring to is the practice of name
construction following the type construction, e.g. pch for a pointer
to a ch, etc. Here if you change the representation, you OUGHT to
change the name as well. True enuff, but the fact is that our
* operator applies only to pointers. So the p simply is a warning
that the programmer is using the standard * operator someplace.
If the representation changes, the places where the quantity is
used, should be visited and checked.

With C++ I guess there will be more redefinition of * [] and the other
operators. in that case the primitive abstract tags will be used more
than the type constructions. It will be still hungarian.

even if * or [] are redefined, if you want to distinguish between
a thing "foo" and its handle, it is a good idea to call the handle
pfoo and define the operators so that the *pfoo = foo type match
will be correct.

If yo want to change the widow handle from a integer to a pointer to
a window descriptor, I would stay with the old names ww for the clients.
Within the operations which KNOW how ww is implemented, I would
use the locally descriptive names, say pwwd and understand that a
kind of coersion is taking place from ww to pwwd at the operation
side of the interface. What the client can not or should not know,
need not and should not be encoded into the hungarian type construction.


So, Hungarian and Abstraction can be used together, something
Mr. Dean failed to recognize.
----------
paulkle@microsoft
uunet!microsoft!paulkle

These views don't necessarily represent those of Microsoft Corp.
But what do you think?