Re: Idle musings on doing E over again

(Pardon the top-posting, I'm on a client that won't behave nicely)

Thomas' inheritance use case is pretty much exactly how users are stored in ldap databases. The schema definitions define a top level User that gets inherited multiple levels down until you hit the typically used inetOrgUser, which sometimes gets extended.

ldap records normally carry around all of the types up the schema definition tree that they inherit for faster searching by object type, but that need not be so. OO languages that have built in ldap libraries normally instanciate them as their most specific type and let the languages inheritance mechanism check if they are usable in a call that takes a type that they inherit from.

So I suppose my point is that there are LOTS of very large object databases where Thomas' use case is a very common occurrence. Many of these corporate ldap databases I've dealt with in a past life as an infrastructure consultant have user types that get extended in java with all kinds of company specific data tacked onto them.

-David Mercer 


--
David Mercer - http://dmercer.tumblr.com
IM:  AIM: MathHippy Yahoo/MSN: n0tmusic
Facebook/Twitter/Google+/Linkedin: radix42
FAX: +1-801-877-4351 - BlackBerry PIN: 2105FDB2


-----Original Message-----
From: Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]>
Sender: [email protected]
Date: Fri, 12 Oct 2012 10:16:51 
To: <[email protected]>
Reply-To: Discussion of E and other capability languages
	<[email protected]>
Subject: Re: [e-lang] Idle musings on doing E over again

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/
_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang