[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] Defensive consistency and integer overflow
From:       David Hopwood <david.hopwood () industrial-designers ! co ! uk>
Date:       2007-10-01 2:13:17
Message-ID: 470057BD.4050801 () industrial-designers ! co ! uk
[Download RAW message or body]

David Wagner wrote:
> P.S. In Java, with or without extensions to reduce the notational overhead
> of using big integers, there's a minor bit of ugliness: BigInteger is
> not a final class.  This means that code that receives a BigInteger "a"
> cannot rely upon the expression "a + b" to actually perform addition,
> unless the code somehow has knowledge of the exact runtime type of "a".
> 
> At a recent meeting with Adrian and Ping, they raised the suggestion
> that perhaps we should introduce a notion of 'honorarily final' into
> Joe-E.  The idea: add a marker interface, with some name like Library or
> Standard or Final or Semifinal.  Some library classes like BigInteger
> could be marked honorarily Library.  The Joe-E verifier would prevent
> Joe-E classes from subclassing any Library class.  Other Java library
> classes might still be allowed to subclass a Library class, but because
> we know that Joe-E code cannot do so, we can rely upon the behavior of
> objects of that type.
> 
> The advantage of this idea is that it would allow Joe-E code to use
> the static type system to establish trust in the behavior of objects
> it receives.  The disadvantage is that we would have to make a decision,
> for once and for all, about which classes are marked Library.  If some
> Joe-E apps would like to be able to subclass BigInteger and others would
> like to be able to rely upon the impossibility of subclassing BigInteger,
> this approach becomes problematic.
> 
> Ping also raised the suggestion of a programming discipline where any
> time a method accepts a parameter of non-final type, the programmer should
> annotate it (e.g., @nonfinal) to help indicate that the behavior of that
> parameter cannot be relied upon.  Then one could build a lint-like type
> that warns about any method parameters whose type is non-final and that
> doesn't have a @nonfinal annotation.

In Sather, subclassing does not imply subtyping. Although the design of
Sather's type system was AFAIK not explicitly motivated by security, it
solves the above problem in a rather elegant way:

 - whenever a class name is used as a type (called a "concrete type"),
   only direct instances of that class belong to the type, and so the
   class behaviour can be relied on;

 - implementation inheritance from any class is possible;

 - there is no need to make any decisions about which classes are "final":
   every class can be used both as an implementation superclass and as a
   concrete type;

 - there is a clear, but lightweight, enforced syntactic distinction between
   the names of abstract types and concrete types: abstract type names start
   with '$'. This aids code review by making interface polymorphism explicit
   in type declarations;

 - it is possible to declare a supertype of an existing (abstract or
   concrete) type, without changing the declaration of the existing type.
   This is useful to correct insufficiently general design of an
   object-oriented API, whether it is part of the standard library, or
   otherwise not desired to be changed;

 - there is no overhead in program size, because:

    * there is automatically an abstract type $Foo corresponding to the
      public interface of any given class Foo -- it doesn't have to be
      explicitly declared. (I am unconvinced by the argument sometimes
      put forward in support of C's header files and Ada's package
      specifications, that *requiring* explicit declaration of all
      interfaces is helpful.)

    * there is a syntactic shortcut for the common case where a subclass
      relationship coincides with a subtype relationship.

IMHO, Sather gets inheritance and subtyping almost exactly right for a
statically typed ocap language. (Instead of inheritance, I would prefer
traits, and/or delegation with delegate(s) fixed at the creation of a
given object, but that's a separate discussion that is mostly independent
of the issues above.)

The one potentially useful ability that Sather does not support (which is
not in conflict with any of the above) is declaring a type that has a
*closed* set of implementing classes. In E, this can be achieved by use
of closely held Stamps.

Sather's type system is described in more detail at
<http://www.icsi.berkeley.edu/~sather/Publications/tr-93-064.html>.
The main language home page is <http://www.icsi.berkeley.edu/~sather/>.
The language is no longer under active development, but is quite well
documented, and is a goldmine of good language ideas (array "slices" and
"iterators" are other Sather features that have been adopted by several
languages).


Unfortunately I can't see any practical way (but that is not to say that
there isn't one) to adapt this approach to Java or Joe-E: the assumption
that subclassing implies subtyping is relied on too heavily.

-- 
David Hopwood <david.hopwood@industrial-designers.co.uk>


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]