Adam Heath wrote:
It's generally bad form have an object take a parameter, then not internalize said parameter. Ie, the array constructor doesn't take ownership of the pathElementArray, thereby allowing calling code to manipulate it. If this is by design, it should be listed as such in the javadocs.
That was by design. I didn't put a great deal of thought into that class initially - it started out as a convenience. As development progressed, it evolved. Writing JavaDocs is a LONG way off.
A lot of the improvements you suggested (and are committing) I would have gotten around to eventually. My focus was to get it operational so it can be evaluated.
By evaluated I mean on a higher level than what you're doing here. I need the *concept* evaluated and commented on. Will this approach to security work? Can we agree on its advantages? Try converting a component over to the new security - was it easier or harder than expected? How will this fit in with your projects? How can it be expanded/improved/made easier?
-Adrian
