static class "Functions" within a namespace

[Karl-Heinz]

the code below throws two errors:

error XS0103: The name 'Test1' does not exist in the current context
error XS0103: The name 'Test2' does not exist in the current context

Test1() and Test2() exist, but only when qualified names are used they become visible to the compiler. when you activate the #DEFINE __OK__ the name of the static class changes from "Functions" to "Funcs". Now it compiles. It seems the compiler gets confused when the name "Functions" is used within this context.

Code: Select all

// #DEFINE __OK__

#IFDEF __OK__
 USING STATIC khr.Funcs

#ELSE
 USING STATIC khr.Functions
 
#ENDIF 



FUNCTION Start( ) AS VOID

     #ifndef __OK__ 

     // ok, gives no compiler error
 
	 ? khr.Functions.Test1()
	 ? khr.Functions.Test2() 
	 
     #endif 


	? Test1()
	? Test2() 
	
	
RETURN 



BEGIN NAMESPACE khr

#IFDEF __OK__
	STATIC CLASS Funcs
#ELSE		
    STATIC CLASS Functions
#ENDIF     	
    	
     STATIC METHOD Test1()  AS STRING
     	 	
     RETURN "Test1() called"
	
     	
     STATIC METHOD Test2()  AS STRING
     	 	
     RETURN "Test2() called"	
      	
     	
     END CLASS 	


END NAMESPACE

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Yes, this is because the compiler also creates a class named "Functions" under the hood, as a placeholder for all FUNCTIONs, GLOBALs and DEFINEs declared in the code, so your Functions class conflicts with the compiler generated class. I am afraid it will not be easy to fix that, so I suggest lways doing what you did, name your own class as "Funcs", this is what I always do as well. Having said that, it's probbaly a good idea for the compiler to identify this situation and give a better error message, though, will log this, thanks!

Chris

[Karl-Heinz]

Hi Chris,

ok i see what you mean, and what´s added to such a "Functions" class. Question: When i create a DLL from the code below with undef __INCLUDE__ such a compiler generated "Functions" class would not really be needed, right ?

Code: Select all

// #define __INCLUDE__ 
 
BEGIN NAMESPACE khr2

#IFDEF __INCLUDE__
    // ---------------
	GLOBAL GLOBAL_Khr2 := 0 AS INT          // part of the compiler generated static "Functions" 
	DEFINE DEFINE_Khr2 := "1234" AS STRING  // part of the compiler generated static "Functions"  
   FUNCTION GLOBALFunc_khr2() AS INT        // part of the compiler generated static "Functions"  
   	RETURN 12 
   	// ----------------
#ENDIF
 
		
	STATIC CLASS Funcs
   	
     STATIC METHOD Foo()  AS STRING
     	 	
     RETURN "X# Foo() called"			
   
   END CLASS 
   

END NAMESPACE 


BEGIN NAMESPACE khr

#ifdef __INCLUDE__
    //  -----------------
	GLOBAL GLOBAL_Khr := 0 AS INT          // part of the compiler generated static "Functions" 
	DEFINE DEFINE_Khr  := "1234" AS STRING  // part of the compiler generated static "Functions" 
    //  -----------------	
#endif        
                  

	STATIC CLASS Globals
		
       CONST BUFFER_SIZE := 512 AS INT 
       STATIC FILE_NAME := "Output.txt" AS STRING  
       STATIC INITONLY CODE_PREFIX := "US-" AS STRING   
       
	END CLASS   
	
#IFDEF __INCLUDE__
   // ---------
   FUNCTION GLOBALFunc_khr() AS INT         // part of the compiler generated static "Functions"  
   	RETURN 12	
    GLOBAL GLOBAL2_Khr := "asdasd" AS STRING  // part of the compiler generated static "Functions"  
    // -------------
#ENDIF     
    


	STATIC CLASS Funcs
   	
     STATIC METHOD Test1()  AS STRING
     	 	
     RETURN "X# Test1() called"	
     	
     STATIC METHOD Test2()  AS STRING
     	 	
     RETURN "X# Test2() called"	
      	
     	
     END CLASS 

 
END NAMESPACE

to make it easier to see what i mean i´ve attached both dlls.

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Yes, theoretically it is possible to make the compiler generate a Functions class only when it is really needed, but I am afraid this will add much complication to the compiler code, intellisense etc, to check if each referenced library does have such a class or not etc. Unless Robert thinks it's relatively easy to allow this...

Chris

[FFF]

Guys,
why has the compiler to use "Functions" ? It knows what is meant, so it could use whatever, e.g., "Others"... How many people will study the compiler output vs the many end coders?
Just a thought...
Karl

[robert]

Karl
We have chosen the Functions name to be compatible with Vulcan.
When we are fully self supporting we will most likely switch to another name that has no risk of conflicts, such as XSharp$Functions.

Robert

[Jamal]

Hi,

I wish you guys just disassociate X# from Vulcan baggage for good. I doubt there are many Vulcan developers who actually use it.

Jamal

[Karl-Heinz]

Guys,

ok, compatibility with Vulcan is a valid point. And yes, at least another name like "XSharp$Functions" would be a step forward.

JFTR: Based on the KHRFuncsLibX_2.dll content i´ve attached a C# compiled Dll - of course with a namespace class "Functions"


regards
Karl-Heinz