Re: [MirageOS-devel] Error handling in Mirage - request for comments!

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le mardi, 3 fÃvrier 2015 Ã 20:25, Thomas Leonard a Ãcrit :

> The problem is that the subclasses get added elsewhere. e.g.
>  
> mirage-types's FS may define Read_only, but an ext4 filesystem might
> define e.g. Read_only_file, Immutable_file and FS_mounted_read_only.
> Ideally, generic code catching Is_read_only should also catch the
> specific cases.

Then rather than [`Read_only] you could define [ `Read_only of error_details ] 
where error_details is a universal type [1]. The Ext4 module would then define:

type ro_error = [ `Read_only_file | â ]

and a projection function from the universal type:  

val ro_error : FS.error_detail -> Ext4.ro_error option

In any case I dont think inheritence/hirerachy is going scale and solve that 
problem well in general. As with any kind of (non multiple) hierarchical system 
you quickly end up wanting to put something in two different branches.

Best,

Daniel

See e.g. https://github.com/samoht/assemblage/blob/master/lib/as_univ.mli

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel