Hello,
I've spend some time to look to internals of namespaces, but I still do not feel myself a right person to give any suggestion about the future development of it. I do not have any function name collision problems in my applications, and old Clipper namespace-less style satisfies my needs. Some C52/C53/Harb/xHarb function compatibility issues could be solved using namespaces, but I guess the purpose of it should be wider than that. Maybe other people (perhaps, who uses namespaces in other programming languages) can give more smart and more far-sighted suggestions for future development of namespaces. Best regards, Mindaugas Ron Pinkas wrote: > Mindaugas, All, > > Did you get a chance to review the implementation, as well as my > answers? > > I'd like us to proceed with implementing our system namespaces, and > it's important the foundation is accepted before we proceed. > > Ron > > On Mar 5, 2008, at 11:51 AM, Ron Pinkas wrote: > >> Mindaugas, >> >> <<< >> I haven't looked to the implementation details yet, but sample code >> does >> not made me clear, how namespaces should be used. Just too many: >> >> NAMESPACE MyNameSpace >> EXTERNAL NAMESPACE MEMBER <SomeFunc> >> RUNTIME NAMESPACE MyNameSpace2 >> OPTIONAL NAMESPACE MyOptional >> USING NAMESPACE MyNamespace >> WITH NAMESPACE MyNamespace2 >> IMPLEMENTS NAMESPACE SubExtern >> FUNCTION <SomeName> IMPLEMENTS NAMEDSPACE <NamsespaceName> >> Sorry, the confusion is obviously because I didn't have the time to >> produce docs, and thus squeezed almost all possible functionality >> into a single sample. This forced an unrealistic and probably very >> confusing sample. Following is an attempt for preliminary docs: >> >> Namespace definition syntax: >> ---------------------------- >> >> 1. [OPTIONAL|RUNTIME|IMPLEMENTS] NAMESPACE <Name> >> ... >> END >> >> The ... can be any combination of: >> >> - Procedure/Function/Class definition[s] >> - EXTERNAL NAMESPACE <SubName> declaration[s] >> - EXTERNAL NAMESPACE MEMBER <Member> declaration[s] >> - Nested NAMESPACE definition[s] >> >> At least one public member must be defined. Functions/ >> Procedures which >> are not explicitly using one of the following attributes: >> >> STATIC >> INIT >> EXIT >> >> are public members. >> >> OPTIONAL >> >> The OPTIONAL attribute tells the compiler that namespace >> functions >> should be visible even without the namespace qualifier. >> Without >> this attribute the namespace functions will only be >> visible to >> code which specifically reference the namespace. >> >> RUNTIME >> >> The RUNTIME attribute tells the compiler to publish the >> namespace >> at run-time so that dynamically loaded code and/or macro >> can access >> namespace members ( explicitly and/or implicitly). Without >> this >> attribute the namespace members are hidden from Macros >> and/or >> dynamically loaded code. >> >> IMPLEMENTS >> >> The IMPLEMENTS attribute tells the compiler that the >> namespace >> definition is the actual implementation of sub-namespace >> which >> was declared elsewhere using the: >> >> EXTERNAL NAMESPACE <SubName> >> >> syntax. >> >> 2. EXTERNAL NAMESPACE <SubName> >> >> This declaration tells the compiler that the sub-namespace >> definition >> exists elsewhere. >> >> 3. EXTERNAL NAMESPACE MEMBER <Member> >> >> This declaration tells the compiler that the definition of the >> member >> function exists elsewhere. >> >> >> 4. PROCEDURE|FUNCTION <SomeName> IMPLEMENTS NAMESPACE <Name> >> >> The IMPLEMENTS NAMESPACE attribute tells the compiler that the >> function definition is the actual implementation of a >> namespace member >> which was declared elsewhere using the: >> >> EXTERNAL NAMESPACE MEMBER <Member> >> >> syntax. >> >> Namespace usage syntax: >> ----------------------- >> >> 1. USING NAMESPACE <Name>[.<SubName>] >> >> The USING NAMESPACE declaration tells the compiler to attempt to >> resolve >> all non qualified function calls using the given namespace. If the >> function called is found as a member of the specified namespace[s] >> (or any of it's outer spaces if any), then the compiler will >> treat the >> function call as-if it was explicitly namespace qualified, i.e: >> >> <Func>([...]) >> >> will be treated as: >> >> <Name>[.<SubName>].<Func>([...]) >> >> Please note that the USING NAMESPACE declaration has a global >> scope, >> meaning it must be placed before any function definition, and it >> will be >> used to resolve all function calls in that compilation unit. >> >> 2. WITH NAMESPACE <Name>[.<SubName>] >> ... >> END >> >> The WITH NAMESPACE ... END code enclosure, tells the compiler to >> attempt >> to resolve all non qualified function calls (inside the closure) >> using >> the given namespace. If the function called is found as a member >> of the >> specified namespace[s] (or any of it's outer spaces if any), then >> the >> compiler will treat the function call as-if it was explicitly >> namespace >> qualified, i.e: >> >> <Func>([...]) >> >> will be treated as: >> >> <Name>[.<SubName>].<Func>([...]) >> >> Please note that unlike the USING NAMESPACE declaration, the >> WITH NAMESPACE closure has a local scope, it only affect function >> calls >> up-to the END statement. >> >> 3. EXTERNAL <Name>[.<SubName>].<Func> >> >> The EXTERNAL declaration tells the compiler to generate a >> reference to >> the specified namespace function, as if such namespace function >> call >> existed in the executable code. The generated code will require >> the >> linkage of the namespace container of the member function. >> >> 4. DYNAMIC <Name>[.<SubName>].<Func> >> >> The DYNAMIC declaration tells the compiler to generate a >> reference to >> the specified namespace function. Unlike the EXTERNAL declaration >> the >> DYNAMIC declaration will generate the reference in such way >> that the >> container namespace is not required at link time. >> >> 5. <Name>.[.<SubName>]<Func>([...]) >> >> The Namespace Qualifier syntax tells the compiler that the >> subsequent >> function call targets the function member of the specified >> namespace. >> This syntax can be used to resolve possible ambiguities. >> >> <<< >> Some comments also looks very scary: >> >> Make sure to compile macronamespace2.prg FIRST >> >> NOTE: You must compile extnamespace.prg FIRST, then namespace.prg >> finally compile tstnamespace.prg and link it as main module with both >> namespace and extnamespace! >> I hope the preliminary docs I provided help to resolve this fear. :-) >> >> Code referencing namespace member functions specifically forces a >> *dependancy* on some other code, to provide the definitions of the >> specified namespace. Normally such dependancy should not be scary, it >> generally means your code uses some 3rd party lib, and the warning >> thus has no real meaning. >> >> <<< >> WARNING 1: You can NOT use USING for Namespaces defined in SAME source >> because you'll create a cyclic dependancy!!! >> I fully understand the intuitive objection to such limitations. I >> believe that if you review the implementation to learn the R/T cost >> saved by using compile time (static) resolution, you'll probably find >> the limitations a fair trade. >> >> FWIW, the advertised limitations are not without workarounds. :-) >> Anyone reviewing the implementation should quickly find very simple >> workarounds. >> >> 1. As long as the namespace definition is not modified you only >> need to compile the source definition *once*. >> 2. As per #1 you just need to add the USING declaration after you >> compile the same source once. >> 3. The cycling limitation is not accurate, you can dismiss the >> limitation if you use forward declaration >> (as of now undocumented syntax): >> >> DEFINE NAMESPACE <Name> >> DEFINE NAMESPACE MEMBER <Func> >> ... >> END >> USING NAMESPACE PATH <Name> >> >> The above forward declaration dismiss the cyclic limitation. >> >> <<< >> WARNING 2: You MUST compile the EXTERNAL module FIRST! >> >> NOTE: More than 1 namespace can use the *same* EXTERNAL NAMESPACE >> unit! >> This is actually a feature not a limitation, it can easily be >> blocked, but what makes it scarry? >> >> <<< >> It seems, there are some restrictions or compile and link order of >> the modules. >> No restriction on compile or link order, the only restriction is that >> valid namespace definition file (.xns) exists when you compile a >> source which uses such namespace. >> >> <<< >> It looks like namespaces relies on function overloading, >> etc. I guess it could be a problem, because users will not be warned >> about wrong compile/link actions and wrong executable will be >> produced. >> Namespace features do not use function overloading, the solution is >> much simpler. Please review generated C code to see how namespace are >> implemented. >> >> <<< >> Note: my opinion is from a few sample .prg files. So, I'm not a >> good >> person to make decisions about future namespace development. I should >> look to current implementation details to understand namespaces >> better. >> Please do Mindaugas, I'll greatly appreciate your input. >> >> Ron ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
