Thoughts From The Abyss

[Matthew Tuck]

A few miscellaneous thoughts:

Hans-Dieter's transparent names are easily implementable as shorthands
if we don't use prototyping, and hence don't require any extra features.

Type layout should never attempted before everything is known, since it
prohibits elimination of unused methods, etc., which I suspect is a big
cause of bloat in existing OOP systems.

View Hierachy
-------------

The are four basic relationships I have described so far: (a)
containment (b) type inheritance (c) impl inheritance and (d) impl
implementing type.

There are various hierachies of display in the intelligent editor we
might choose.  Ie What lies below what in the tree (or directed acyclic
graph in some situations) structure that makes up the program?

The first three demonstrate the containment relationship.  Containment
is implicit in the structure and other relationships need to be written
explicitly in the text.

Nesting:  The physical containment hierachy.  There is no relationship
between subtypes and impls and types.  The only relationship is that of
nested types/nested impls/methods/fields in their types/impls.

Nesting (Detached): Same as above except elements that are "detached"
(see "Modules) would be shown at the top level instead of in their
normal positions.

Nesting w/ Modules:  Same as above except that the separate modules as
the top level.  Detached elements in different modules must be shown
detached.  Detached elements in the same module might be shown either
way, and this might be presented to the user as a choice.

Type Inheritance & Implementation:Types are displayed in their type
hierachy (MI would result in the type appearing in multiple places in
the tree).  Impls are displayed beneath their implemented type.  All
other relationships are written explicitly.

Type Inheritance & Impl Inheritance:  The two separate relationships are
present are represented in two different trees with no implicit
relationship between types and impls.

There are also different possibilities, e.g. flat views with no tree
structure making a relationship implicit.  There's a range of
combinations that could be supplied to the user, and which to user is a
choice to be made.  It seems to me there's benefit in allow the user to
switch between and choose them.

Read-Only Views
---------------

Another purpose of read-only views that have come up a couple of times. 
The existing suggestions were to support read-only code that someone
else is working on in a cooperative environment, and to prevent editing
code that is generated from a higher level in the translational
hierachy, ie machine code generated from Ultra HLL.

I first realised that views might not want to support all language
features.  There are several reasons for this:

(a) A view might be special purpose, and support doing something really
well, but not both with everything
(b) It provides a way of use a view in development and not complete
(c) A programmer might want to hide details and hence not use certain
features.  The view could be written to not use them.  When it discovers
code someone else wrote that uses them, it can't handle them, so you'd
have to use another view.

Hence there might be a need for a "read-only" concept, where the view
may or may not display a helpful description of the program tree, and
doesn't allow it to be changed.  The scope of this could be a very small
part of the program tree or it could be large.

This might not be always the case.  For example in (c) the view might
support displaying the "frowned upon" feature, leaving it as it is,
supporting changing it to an acceptable value, although not to an
unacceptable one.  But if there is a facility to mark a tree as
"read-only", we could use it for this.

If we have detached elements, both generated code and access control
could occur on very deep in the tree, the same as this.

Exactly how this would work I'm not sure.  Obviously the view would not
need to support this if it supports everything.  But it would be useful
if we moved "read-only" functionality away from the view and into the
language and possibly even the editor, so it's useful for everyone.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/