Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Data hiding and type safety

4 views
Skip to first unread message

Anton

unread,
Feb 23, 2008, 4:51:23 PM2/23/08
to
Hi all,

I am just interested what is the Pascal way of dealing with
(type) safety and data hiding.

For example, I am writing a module that handles threaded
trees. What should it export?

If I export the definiton of my tree type, I'll disclose my
internals, which is not safe (no data hiding); on the other
hand, if I don't do it, the interface functions will have to
operate with an index or a pointer to indentify a tree inside
my module, which is not type safe...

Doesn't Extended Pascal deal with such problems by offering
restricted types?

Thanks in advance,
Anton

John Reagan

unread,
Feb 25, 2008, 4:06:38 PM2/25/08
to
Anton wrote:

> Doesn't Extended Pascal deal with such problems by offering
> restricted types?

Yes, EP added restricted types in lieu of an OO system with private
data. I'm not a big fan of the direction the committee took with those
features.


--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

Anton

unread,
Feb 25, 2008, 5:13:23 PM2/25/08
to
Thanks for the reply, John!

> Yes, EP added restricted types in lieu of an OO system with private
> data. I'm not a big fan of the direction the committee took with those
> features.

But that's great: good data hiding without the OOP pains!

My main queston was: how do Standard Pascal programmers deal
with this? I mean, I might be missing a way of avoiding this
dilemma of either exporting types or function that work with
"pointers". And if it exists, then which of the alternaties is
usually chosen?

Anton

John Reagan

unread,
Feb 26, 2008, 11:20:58 AM2/26/08
to
Anton wrote:

> My main queston was: how do Standard Pascal programmers deal
> with this? I mean, I might be missing a way of avoiding this
> dilemma of either exporting types or function that work with
> "pointers". And if it exists, then which of the alternaties is
> usually chosen?
>
> Anton

In 7185 Pascal, there isn't a language feature to protect/abstract
a record's implementation. Just lots of documentation, honest
programmers, and code reviews.

--
John

Anton

unread,
Feb 26, 2008, 4:20:49 PM2/26/08
to
John Reagan:

> In 7185 Pascal, there isn't a language feature to protect/abstract
> a record's implementation. Just lots of documentation, honest
> programmers, and code reviews.

Honest progrmmers -- Great!
Code reviews -- Good!
Docs -- Hmmm, whad docs do you mean?
if it's the standard Pascal site, then
most of them are historical...

Anton


John Reagan

unread,
Feb 27, 2008, 2:16:09 PM2/27/08
to

No, the docs you write to give to your honest programmers telling then
which fields in the record are "public", which are "private", and what
you'll do to them if they cheat. You might want to use some naming
convention as an aid.

--
John

Anton

unread,
Feb 27, 2008, 3:14:40 PM2/27/08
to
John Reagan:

> No, the docs you write to give to your honest programmers telling then
> which fields in the record are "public", which are "private", and what
> you'll do to them if they cheat. You might want to use some naming
> convention as an aid.

Oh, and I suppose you mean peer reviews of code?

John Reagan

unread,
Feb 27, 2008, 3:53:08 PM2/27/08
to
Anton wrote:

> Oh, and I suppose you mean peer reviews of code?
>

We do peer review for most complicated items. I don't bother for
trivial edits, but during certain critical periods (like just before
field test or release), we review everything just so we don't break the
nightly build and waste a day. I don't use any particular formal review
method, but there are several styles that might be helpful.

Personally, for complicated bugfixes or new features, I do test reviews
as well. In the past, I've made engineers write their tests (and have
them reviewed) before they write their code (plus more tests afterwards
if desired).


--
John

0 new messages