Re: Idle musings on doing E over again

Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]> Fri, 12 Oct 2012 10:16:51 +0100
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
On 2012-10-10 14:56, Kevin Reid wrote:
> On Oct 10, 2012, at 2:04, Thomas Leonard wrote:
>> On 2012-10-07 17:43, Kevin Reid wrote:
>>> On Oct 2, 2012, at 4:24, Thomas Leonard wrote:
>> [...]
struct User { name :String, email :Email }
>>>>
>>>> If "u" is received over the network then the system should verify its
>>>> structure and reject it if it's wrong. But when passing between
>>>> functions within a vat, it shouldn't keep rechecking it.
>>>
>>> Yes, this is what I have in mind. In particular, what I am currently
>>> thinking is: records have an optional "type" reference. When the User
>>> guard gets an untyped (or wrong-typed?) record, it checks the record
>>> against the declared structure and produces a new record with the
>>> matching type. Thus, if the type already matches we have an O(1) check
>>> after the conversion.
>>
>> Sounds reasonable.
>>
>> What about extra fields? It would be useful to accept a record with at least the two fields above, but still preserve any other fields.
>
> That very much does not fit into my scheme. Could you outline some use cases?

It's generally useful to support backwards-compatible updates. e.g. a future 
version of the service might declare:

struct User {
   name :String,
   email :Email,
   phone :nullOk[Phone] := null,
}

If a user registers with extra details that an old version doesn't need then 
it can just store them in the database anyway. No need to reject the message.

(in OO terms, you might say e.g. "interface NewUser extends User", and 
services which need a User will also accept a NewUser)


-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: +44 23 8059 8866

mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk/