NewsForumsCodeLogsGallerySpecsSearch

Global Functions not visible to Extended Types

BlitzMax Forums/BlitzMax Beginners Area/Global Functions not visible to Extended Types

Gabriel(Posted 2005) [#1]
I think this is best explained in code.

This works :

Type Base
   Global A:Int
End Type

Type Ext Extends Base

   Function DoStuff()
      Super.A=10
   End Function
End Type


And this doesn't :

Type Base
   Global A()
End Type

Type Ext Extends Base

   Function DoStuff()
      Super.A=DoOtherStuff
   End Function

   Function DoOtherStuff()
      Print "BLAH"
   End Function

End Type


And the reason it doesn't is that Identifier Super.A is not found.

Is it my syntax ( It's 4am as I type this, so I could have messed something up ) or is this supposed not to work? Solution?

BTW it works just fine if I move the functions out of the type. But then I've destroyed the aim of keeping everything self-contained.


GW(Posted 2005) [#2]
hmm.. global variables can be function pointers for Type functions.
ex: "global G(arg) = Type.Function"
but I couldnt get your example to work with any variation.


Gabriel(Posted 2005) [#3]
Yeah, it's a little odd, but I guess it's not the end of the world to move the functions outside of the type definition.


Who was John Galt?(Posted 2005) [#4]
In your first example, you can just type 'A=10' in DoStuff as the global is inherited (super not necessary)


Type Base
   Global A()
End Type

Type Ext Extends Base
   Function DoStuff()
      A=DoOtherStuff
   End Function

   Function DoOtherStuff()
      Print "BLAH"
   End Function

End Type


This runs - not sure why the original version doesn't - perhaps because if you specify super.A then DoOtherStuff is out of scope - though I'm not clear on if/why this is the case.


Dreamora(Posted 2005) [#5]
If you extend, you don't have to use super.
Super is only if you redefine a function with a new one to call the previous version. (like a new creation function which calls the previous one)


Gabriel(Posted 2005) [#6]
Yep, I was using Super because the extended type has it's own function with the same name. I guess it just isn't possible, but it's easy enough to work around.


fredborg(Posted 2005) [#7]
Use Base.A instead of Super.A, like so:
Type Base
	Global A()
End Type

Type Ext Extends Base

	Function DoStuff()
		Base.A = DoOtherStuff
	End Function

	Function DoOtherStuff()
		Print "BLAH"
	End Function

End Type

Ext.DoStuff()
Base.A()
I have no idea why Super doesn't work, as it should do the same internally.


Koriolis(Posted 2005) [#8]
No, it shouldn't do the same. 'Super' is equivalant to 'Self' that you retyped to the base type rather than the current one.

A bit as if you had done (Base(Self)).MyMethod(), though it's actually not the same because when calling a method via Super, it also forces a non-virtual call (simply put it really forces to call the base class method, unlike "(Base(Self)).MyMethod()").

It really names an object instance, but you are trying to access something that is part of the class, not of an instance of the class.
So it actually makes sense that it doesn't compile, while on the other hand Base.A() does.
"Base" names a class, "Self" and "Super" name objects. Much different.

That is not to say that Mark couldn't have made "Super.A" to work (actually even C++ allows to access static class data through an object of this class), but in any case BlitzMax is clearly not inconsistent in not allowing "Super.a" to compile, quite the opposite.


Gabriel(Posted 2005) [#9]
It really names an object instance, but you are trying to access something that is part of the class, not of an instance of the class.


That was my first explanation too, but if that's the case, why does it compile just fine if A is an integer? It's only if A is a function pointer that it fails.


Fredborg: Doh, yep, that obviously works. I have no idea why I didn't think of it. Guess I just assumed it wouldn't since super didn't. Thanks.


Koriolis(Posted 2005) [#10]
Well if it does, it qualifies indeed as a compiler bug.
Except when I try your sample with the global type int, it doesn't compile. Are you really really sure you made it compile? If so, which version of BlitzMax do you have?


Gabriel(Posted 2005) [#11]
You're right the example I gave actually doesn't work. I made the example up to save posting a huge chunk of code for a small question, and never verified it worked. Now I don't know what I changed to make it stop working. I'll take another look.


ziggy(Posted 2005) [#12]
This example prints BLAH in the console window, without any error. 

Type Base
   Global A()
End Type

Type Ext Extends Base
   Function DoStuff()
      A=DoOtherStuff
   End Function

   Function DoOtherStuff()
      Print "BLAH"
   End Function

End Type

ext.DoStuff
ext.a



Dreamora(Posted 2005) [#13]
Sybixsus: In that case a real show off of the problem might perhaps be of more help than an example thats plain nonsense and in normal shouldn't even work.

super.a if there is no a redifinition within the extended type is nonsense and a real compiler would stop and mention that you call super without any need.