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 [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
