NewsForumsCodeLogsGallerySpecsSearch

Why does this not compile?

BlitzMax Forums/BlitzMax Programming/Why does this not compile?

Gabriel(Posted 2006) [#1]
Type A
   Const Anything:Int=1
End Type

Type B Extends A
   Function DoSomething(C:Int=Anything)
   End Function
End Type


If I change it to 

Type B' DOES NOT EXTEND A ANY MORE
   Const Anything:Int=1
   Function DoSomething(C:Int=Anything)
   End Function
End Type


It compiles fine. So why won't it compile the first way? It *is* constant, and it should be inherited. So what's the problem?


skidracer(Posted 2006) [#2]
Like C, unfortunately parameters do not inherit the scope of method (no I don't know why your second example compiles) so you need this:

Type A
   Const Anything:Int=1
End Type

Type B Extends A
   Function DoSomething(C:Int=a.Anything)
   End Function
End Type



Gabriel(Posted 2006) [#3]
Ok, fair enough. I probably wouldn't have queried it if I hadn't found the second one worked. Thanks for clearing it up.


skidracer(Posted 2006) [#4]
Given your second one works, I'm thinking perhaps Mark's intention was to give parameters access to function global scope or whatever and maybe with another tweak your first example could compile in future, would be a good thing IMHO.


gman(Posted 2006) [#5]
in the second, the const Anything is redefined in B giving the functions of B access to it.


H&K(Posted 2006) [#6]
lol @ Gman

The point is that is that the first example, B should also have access to Anything. As it is a part of B. It not a question of why the second works, but rather why the first doesnt.

Weird though isnt it. I would concider it a bug, as althoght a.anything is a workround C:int= Anything is intuitivly what you would do. As further example of the fact its a real Bug

Type A
   Const Anything:Int=1
End Type

Type B Extends A
   Function DoSomething(C:Int=b.Anything)
   End Function
End Type

Also works, so it does know that both b.anything and a.anything are constants. Some part of the precompiler is simply not realizeing so.


Dreamora(Posted 2006) [#7]
Seems like a bug with correct scoping, so in the end, BMs features to "redefine fields" in extends payed back and destroyed default behavior and regular access rules.


H&K(Posted 2006) [#8]
Ummm, I forgotton about that.

If its a tossup between being able to redefine fields or not haveing to state scope in extended fields. I think Id like to keep the redefine fields


Gabriel(Posted 2006) [#9]
I'm not making any comment in regard to whether it's a bug, a feature, a missing feature or whatever, because generally I think Simon is right that it's probably just that Mark originally intended parameters not to have scope within the type at all, and then probably decided it would be useful for them to have global scope and just decided to limit it at that, without adding in inherited global scope..

However, *if* ( and I have no idea if it is or isn't ) giving parameters inherited global scope were to break the ability to redefine fields, then that wouldn't be a good thing. I don't use that ability, but I'm sure others do and I'd hate to break anyone else's code just for this. It's not as though it requires a workaround or anything, it's just a peculiarity and adding scope within the parameters is hardly difficult or time consuming.

So yeah, I agree with Simon. It would be nice to have, and if that little tweak can be done without breaking anything, great. But it's not worth breaking anyone else's code for.