MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Attesting implementations and <type>-map,Match arg order issues
On Mon, Dec 02, 2002 at 10:57:15AM -0500, Polar Humenn wrote:
> Anne said that you had to do an "ugly" hack inorder to implement "map" as
> opposed to <type>-map?
> Could you explain what that is and why you feel it's ugly?
[note that these comments are purely implementation issues, and are not the
cause for my feelings on the map/type-map debate]
Well, it's not _that_ ugly a hack, it's just not all that clean, which makes
me a little upset (I'm kinda proud of my code, and I hate to unleash this
issue on unsuspecting programmers <g>).
With all the other functions in the spec, there is a known return type [1], so
a factory can be used to create a function based on a URI, and then any code
that contains that function can ask the function for its return type. This
is done to verify that the policy is valid, and to make sure that the types
being passed around match the function definitions. Map, however, is a special
case [2], since its type is not known until you consider its parameters. This
means that our code will need to do one of two things:
1. Require code using the factory to check first if it's the map function,
and call a special method if it is, providing the type of bag returned
by this map function (harder on the programmer and more expensive for
every policy used, but undoubtedly the right thing to do)
or
2. Allow functions to say just that they return bags, and at run-time
determine if the right type is being provided (easier on the programmer,
but generally a bad idea, since it results in re-evaluation of
invalid policies and makes the type-checking less robust)
In both cases, there is a second problem for our code, which is that the
factory provides singletons of all functions, since they have no state, and
we can therefore use less memory and less processing time by having only one
instance of any given function. The one exception will be the map function,
which will have to be instantiated with each use since it has state: the return
type, which is inferred by its parameters.
Any implementation will have its pros and cons, and any implementor has to
make choices about how to build things. This mail has expressed a few of the
choices that we have made (which was particularly difficult since until a
month ago, the spec was still in violent change, which made it challenging
to keep the design coherent). I don't want to get into a discussion at this
point about smart design choices. Our implementation supports all the
features of the spec (except map), and is still pretty extensible, making
it easy for a programmer to add any features they want. The issue of map is
a little sticky, but as I said in mail to the TC list earlier this morning,
regardless of the TC's decision on the map issue, our implemenation will be
able to handle it in short order.
Does that answer your question? I don't want to go too much more into what
we've written right now, but if I've missed something, let me know.
seth
[1] No, I don't consider "bag" to be a return type, because most of the
functions are defined to operate on specific kinds of bags, so I want
to check the type in the bag, not just that it's a bag. I could be
looser about this, doing run-time checks instead of one-time up-front
checks, but I'd rather be stricter where I can and do the check once
to make sure that the policy is correct.
[2] Note that I would have written the code differently were this the rule,
and not the exception (ie, had other generic functions not been defined
as type-* functions with known return types). I might also have designed
our code differently if functions like map had existed earlier in the
lifecycle of the spec.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC