Opaque / abstract types ?
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 bugs.ecmascript.org ticket/166.
From the Outline, operator "as"
No such operator -- did you mean "cast"?
On Sun, 2007-10-28 at 11:45 -0700, Brendan Eich wrote:
A class with a private constructor. See 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.
-----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
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.)
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 ?