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: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > ------------------------------------------------------------------------- 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
