OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [xacml] RE: Your input needed on Comment#33. Forwarded messag efrom Daniel Engovatov.

On Mon, Nov 25, 2002 at 10:29:03AM -0500, Polar Humenn wrote:
> What we have here is the generic application of the SAME FUNCTIONALITY, so
> why give the same functionality different names?
Because this is how it is done with every other function in the spec. As a
result, you need this for the map function too if you want consistency. Yes,
I see the value of having a generic function that can map any type to any
type, but it breaks the type system that the rest of the spec has defined. Both
Daniel and I are speaking from an implementors point of view, and we both
see the muddle that occurs when you have this special-case function. The clean
definitions in the spec completely break when you allow the map function to
not have its return type explicitly defined.

Implementors will already need to define things like -equal, or -one-and-only,
or -union for their new attribute types. Redefining the map function doesn't
change this. A good implementation will let a programmer do this with a
minimum of effort, but it is still necessary. To maintain consistency, and
to keep the type system intact, the map function must become type-map.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC