Opaque / abstract types ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Opaque / abstract types ?

David Teller-3
   Hi list,

 After reading the Outline document, I find myself wondering if there's
a way to provide a type without any method for the user to manually
create an inhabitant of that type ?

 This is a technique commonly used in functional programming (and
sometimes used in Java/C#, too, I believe) to provide type-checked
safety / security, e.g. you can only call function "read_from_file" with
an argument of type "FileOpenedForReading", which itself may only be
obtained from function "open_file" and cannot be forged. Of course, this
example applies to files, but could just as well apply to any kind of
credential.

 From the Outline, operator "as" and reflexivity make me think it's not
possible. Am I wrong ?

Cheers,
 David

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opaque / abstract types ?

Brendan Eich-2
On Oct 28, 2007, at 5:45 AM, David Teller wrote:

>    Hi list,
>
>  After reading the Outline document, I find myself wondering if  
> there's
> a way to provide a type without any method for the user to manually
> create an inhabitant of that type ?

A class with a private constructor. See http://bugs.ecmascript.org/ 
ticket/166.

>  From the Outline, operator "as"

No such operator -- did you mean "cast"?

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opaque / abstract types ?

David Teller-3
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 ?

> >  From the Outline, operator "as"
>
> No such operator -- did you mean "cast"?

I actually meant "wrap", but yes, "cast" worries me, too.

Cheers,
 David

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Opaque / abstract types ?

Lars Hansen-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss