On Tue, 18 Jun 2002 13:14, Peter Donald wrote: > Hi, > > As I understand it now the <import/> tasks actually deploy the library (ie > make it available). When you use a type, say a task, you can use shortname > and it will be sucked out of last <import/>ed tas with that shortname. To > use a specific type you can also specify it using "namespace.shortname". > > Is this correct?
More or less, though the algorithm for resolving a shortname into a type is closer to how java works. The algorithm is: - Find all types that have been individually <typedef>'d in the current execution frame, whose name is the same as the shortname. - If there is exactly one such type, use that. - If there is more than one, the shortname is ambiguous. Throw an exception. (java analogy = using short name 'c' with a single type import a.b.c) - For each antlib that has been <import>'d or <typelib>'d in the current execution frame, search for a type whose name is the same as the shortname. - If there is exactly one such type, use that. - If there is more than one, throw an exception. (java = on-demand import a.b.*) - Resolve the shortname in the parent execution frame, using the above algorithm. Do this recursively up to the root execution frame. - The core antlibs are implicitly imported in the root execution frame (java = implicit import java.lang.*) It's a little broken at the moment, because the types in an antlib are deployed one-at-a-time, rather than all-at-once. So, there's no difference (as far as the user can see) between antlib types and <typedef>'d types. DefaultTypeManager works correctly; the DefaultDeployer just needs a bit of tweaking to deploy antlib types in one chunk, instead. Something that Darrell was talking of doing was to add some way to exclude certain types from shortname resolution, eg. when you <typedef> or <import>, you specify that the type(s) should be made available via qualified names only, ie "namespace.shortname". > Do you think we should move further towards java import model or is it good > as it stands? Java model. Just have to fix the deployer and we're done. > What I mean is that should all librarys be deployed at start. > Then the <import/> statements just set the list of namespaces that we > search in for a type. So if we import namespace A, B and C. Then we end up > looking for task foo we would first check A.foo, then B.foo then C.foo and > using first type we find. > > Ignoring the performance penalty (which I think we could deal with by > caching the deployments) do you think it is a good idea or not? A good idea. One thing I was thinking of doing, is to push parsing the antlib descriptor, and assembling all the RoleInfo and TypeDefinition objects, behind the Library and LibraryManager interfaces. That would take care of the caching issue, since the LibraryManager does caching. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
