Re: Interfaces / data types in E

On Oct 6, 2011, at 6:35, Thomas Leonard wrote:

> We've got quite a few methods that take or return maps. e.g.
> 
> to purchase(customerDetails :Map[String,any]) {
>   ... customerDetails["name"] ...
>   ...
>   if (problem) {
>     notify(customerDetails["email"])
>   }
>   ...
> }

When you say "We" do you mean the E project or one of yours?

> The problem is that it's not obvious from the method signature what keys 
> need to be present. Often someone fails to include a mapping, and the 
> system only fails later in some case where it needed that value.
> 
> What I think I'd like to do is something like:
> 
> def CustomerDetails := makeNamedTuple([
> 	"name" => String,
> 	"email" => String,
> ])
> 
> ...
> 
> to purchase(customerDetails :CustomerDetails]) {
>   ... customerDetails["name"] ...
> }

I think this is a fine guard to have. For consistency with other parameterized guards, it should be written NamedTuple[[...]].

Also, I think a better name would be "Record", with one caveat: we may wish to introduce record objects at a later time which have explicitly defined type objects and non-dynamic fields. Thus perhaps "MapRecord" instead...?

> So that:
> 
> - if the caller fails to provide "name" and "email" then it fails the guard
> - if I try to access a field I didn't define (e.g. "fax") then I get an 
> error, whether or not the client provided it, so I'm forced to keep the 
> interface up-to-date

The latter requires that the guard wrap its parameter. That is a perfectly fine thing to do, but it shouldn't be "normal behavior" and so should be clearly indicated in a noun or verb.

> Any ideas on the best way to do this? Maps? TermTrees?

Term-trees are not suitable for general purposes because they cannot contain arbitrary objects (not even arbitrary Data objects).

> Some of the other systems using this are written in Java, so ideally it 
> should be easy to use from there too.

Since Java idiom would be to define a class to hold the record contents, this suggests that the record objects I mention above would be a better E idiom than using Maps, if you want interoperation.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>