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

[Polar Humenn <polar@syr.edu>]

On Mon, 25 Nov 2002, Seth Proctor wrote:

>
> 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.

Not true. "integer-equal" is fundementally different that "string-equal",
etc.  Map is generic, or polymorphic over "bags".

And, "integer-equal" specifies a function that determines equality over
integers (i.e. as arguments). If you took your approach to naming the map
functions, e.g. "integer-map" naming the resultant type only, then to be
"consistent" you would really have to name the "integer-equal" function as
"boolean-equal", which doesn't make sense.


> 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.
>
>
> seth
>