#PB_Compiler_CountProcedureParameters

[Josh]

Calling a procedure with default parameters, i have no secured possibility to check inside the procedure, is the default parameter set or not.

Having a compiler constant like #PB_Compiler_CountProcedureParameters or a function like GetCountProcedureParameters(), I could do some nice things. For example simple properties in one procedure:

Code: Select all

CubeColor (*Cube, #Red)
Debug CubeColor (*Cube)

[luis]

i have no secured possibility to check inside the procedure, is the default parameter set or not.

If it's the default value for a parameter, you don't need to know if it was set by the caller or by the definition of the prototype of the procedure.
It's set, just use it.

Having a compiler constant like #PB_Compiler_CountProcedureParameters or a function like GetCountProcedureParameters(),

I don't understand. PB does not support a variable number of parameters for procs. All the params must be specified, hence the default value if you want to not explicitly specify some of them (still doing it implicitly), and the introduction of #PB_Ignore for some PB commands.

Maybe you are asking to support a variable number of parameters, like printf() in C.

[Josh]

... you don't need to know if it was set by the caller or by the definition of the prototype of the procedure.
It's set, just use it.

Why do you know, what I need?

I don't understand

I see, you don't understand

PB does not support a variable number of parameters for procs. All the params must be specified, hence the default value if you want to not explicitly specify some of them (still doing it implicitly), and the introduction of #PB_Ignore for some PB commands.

PB supports parameters with a default value. #PB_Ignore is no secured possibility to know, is the parameter set by caller or is this the default value. The problem is much larger, if the parameter is a string.

Maybe you are asking to support a variable number of parameters, like printf() in C.

No, if you read my first posting and try to understand, you will know what I'm asking.

[luis]

No, if you read my first posting and try to understand, you will know what I'm asking.

LOL, I tried.

The only reason to have a command to "count parameters" like GetCountProcedureParameters() is if you have a variable number of them.
That's not what you wanted ? Take note: it didn't show.

Seems like you want to know if a default value for a param is the original one set through prototype definition or explicitly by the caller. Again, if you can't distinguish between them that value must be the default. If set by the caller or not does not change the value. So you bet I'm not understanding the need to differentiate between them.
Anyway, the language you used was not exactly not open to interpretation, and the supporting code examples demonstrating the current limitation you are lamenting were... can we say missing ?

I just tried to interpret what you were saying and not for my amusement, of that you can be sure.

True, I don't have a crystal ball, but *my* balls are now inflated enough by your childish barking tone I'll salute you here.

BAH!

[freak]

Optional arguments work like this:

Code: Select all

Procedure foo(a=1, b=2)
EndProcedure

; If you write this in your code:
foo(42)

; The compiler automatically turns it into this:
foo(42, 2)

So under the hood, the procedure is actually always called with all parameters. The compiler changes the places where the procedure is called to pass the optional parameters as well. This is why it is not possible inside the procedure to tell how many arguments were passed. The answer is always: "all of them".

[luis]

No Freak, if you read his first post and try to understand, you will know what he' asking

[freak]

I did understand. He wants to do this: http://www.purebasic.fr/english/viewtop ... 05#p416605

[luis]

I did understand.

Really ? I said the same thing about the parameters not being variable in number and why consequently you need to specify a default etc, and he spitted on my nose. So did I understand too ? Because I didn't think it was possible. Or your nose is about to become wet too ? Oh, well, sorry, wasted enough on the subject to look to external references too.

[Josh]

So under the hood, the procedure is actually always called with all parameters. The compiler changes the places where the procedure is called to pass the optional parameters as well. This is why it is not possible inside the procedure to tell how many arguments were passed. The answer is always: "all of them".

Thanks for explaining, I thought already, that this is running on this system. My vision was the following:

• The compiler is running through my code
• If the compiler finds a line which is calling my procedure, he sees, there is 1 parameters set
• The compiler writes a command, which sets the #PB_Compiler_CountProcedureParameters value to 1
• Immediately after this, the procedure is called and #PB_Compiler_CountProcedureParameters can be used inside the procedure.

That was my humble vision. Don't know, this can run. I never build a compiler

For me it would be enough, if #PB_Compiler_CountProcedureParameters would be a global constant and I see no problems, if the constant is disturbed with a further procedure call inside the procedure.


For example. I'm typing the following code:

Code: Select all

Procedure Test (a, b=7)
  Debug Str(a) + " " + Str(b)
  Debug PB_Compiler_CountSetProcedureParameters
EndProcedure

Test (4)
Test (4, 5)

Compiler intern the code is prepared like this:

Code: Select all

Global PB_Compiler_CountSetProcedureParameters

Procedure Test (a, b=7)
  Debug Str(a) + " " + Str(b)
  Debug PB_Compiler_CountSetProcedureParameters
EndProcedure

PB_Compiler_CountSetProcedureParameters = 1 : Test (4)
PB_Compiler_CountSetProcedureParameters = 2 : Test (4, 5)