On Wed, Jul 28, 2010 at 9:31 AM, René Dorta <renejdorta{([at]})nowhere.xy
I think that CPascal feature is also useful in some cases where a C++ programmer would use the controversial concept of "friend" classes.
René Dorta.
On Wed, Jul 28, 2010 at 8:42 AM, Alexander Iljin <ajsoft.gm{([at]})nowhere.xy
Hello!
> My questions are:
>
> 1. Can you think of any real-world scenarios where this would be useful? If
> so what should the 'interface' show?
The real-world scenario for this is when you don't want to publish
the record type so that client modules can't make extensions. If you
don't publish the name nobody else can use it as a basic type.
The interface definition is correct as it is.
> 2. Can you think of any problems / side-effects associated with being able
> to do this?
The result is also that nobody can create instances of the
unpublished type, so inside the module you can be sure that all the
routines are fed with a correctly initialized entities, because they
originate from the module itself. I think it's a very clever way to
forbid extensions (or to control the object population) without using
additional keywords (ABSTRACT, EXTENSIBLE or LIMITED, which is the
(more flexible) way it is done in Component Pascal).
I use this feature to control extensibility in my Oberon-2 programs.
Also, you can create enumerations with objects like week days:
TYPE
WeekDay = POINTER TO RECORD dayNumber-: INTEGER END; (* the type is
not published *)
VAR
monday-, tuesday-, ... : WeekDay;
PROCEDURE NextDay* (thisDay: WeekDay): WeekDay;
Client modules can only call "NextDay" by passing it an instance of
a variable from the existing global set, but they can't create a new
day.
Of course, then you have another routine to change which day of the
week is considered "first" - Monday or Sunday - by changing the
dayNumber variable inside the set of global objects, and you will be
absolutely certain that there is no other place in client code that
must be updated, because clients can't extend the set.
> 3. Would it be a good thing or a bad thing if a compiler reported an error
> if you tried to export a field from a record if the record type itself was
> not exported?
I don't think it is an error of any kind, so there is no need for a
special message.
---=====---
Alexander
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Wed Jul 28 2010 - 16:03:36 UTC