Opaque / abstract types ?

[Lars Hansen]

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of David Teller
> Sent: 29. oktober 2007 11:30
> To: Brendan Eich
> Cc: JS2
> Subject: Re: Opaque / abstract types ?
> 
> On Sun, 2007-10-28 at 11:45 -0700, Brendan Eich wrote:
> > A class with a private constructor. See
http://bugs.ecmascript.org/ticket/166.
> 
> Can I assume that solution 3) was chosen ?

Until it's written up in a spec I wouldn't assume anything, but since
the ticket said we favored it, it may not be too unreasonable to place
your bets on it.

> > >  From the Outline, operator "as"
> > 
> > No such operator -- did you mean "cast"?
> 
> I actually meant "wrap", but yes, "cast" worries me, too.

Why does "cast" worry you?  All it does is check that a value has a
particular manifest type (which you have to be able to name).  It does
not change any bits, except perhaps in the case of the interconvertible
number and string types (I don't think that has been discussed).  If it
fails it throws an exception.  It's effectively an assertion with a
result type, to aid strict mode.

IIRC, the meaning of "v wrap T" is:

  if (v is T) => T
  if (v like T) => new instance of something looking like T, shadowing v
  else => failure

The meaning of "v like T" is

  if (v is T) => true
  if (T is class/interface type) => false
  if (v is structually similar to T) => true
  else => false

Note that class/interface types "wrap" to themselves only as no-ops: no
bits are hurt.

The consequence is that it should not be possible to create instances of
a class if the class does not want to be instantiated.  (That ought to
be true regardless of what the operators are in the language, of course.
If the constructor is "private" but that can be subverted without aid of
the class then "private" doesn't really mean much; that would be a bug
IMO.)

--lars