On 08/06/14 00:49, Kinney, Michael D wrote: > I do not have any specific issues with the undefined behavior of > these APIs, and I agree with the limited utility of checking for > NULL. I just wanted to make sure the style difference between this > lib class and other lib classes in the MdePkg was on purpose. > > I did misunderstand the behavior of Delete(). Your explanation > helped, and I agree no changes are required.
Thank you very much! > Not sure I see the value in the Validate() API. I can see it could > be useful as an internal API during the development of an > OrderedCollection library instance. What is the use case from a > consumer of the OrderedCollection lib class perspective? The Validate() API is solely there for unit testing, exactly as you say. I made it a public function because the tester application in the third patch (currently posted for AppPkg) uses it. If you have an idea how to improve this arrangement, I'd be happy to hear it! The requirements are: - an independent UEFI or StdLib application should be able to exercise the Validate() API (or something equivalent), - the Validate() API needs direct access to internals. In other words, the unit tester is an application that is a special consumer of OrderedCollectionLib -- it has no purpose per se but to wrap OrderedCollectionLib APIs, expose them to the user, and validate the internals after each read-write operation. I request that you please skim the 3rd patch as well. It will make the intended use of the library APIs clear, and it'll explain how the application helps with unit testing. (I considered putting the application itself alongside the library instance in MdePkg, but I thought that it wouldn't fly. Hence I added the application to AppPkg instead.) In one sentence, the Validate() API is public because I thought that unit testing the library (with whatever actual library instance backing it) is a first class use case. If you have an idea how to hide that role from "business clients", but still expose it to an independent "unit tester client", I'd be glad to hear. (Eg. I could possibly split off the Validate() API to another header file, but I'm not sure where to put it and what to call it. And, any library instance implementing the class should implement Validate() too, despite it being in a "private" header.) Thank you! Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
