Page 1 of 2
Make obligatory the '#' postfix for Macro input params
Posted: Sat Nov 10, 2007 10:56 am
by Psychophanta
Code: Select all
Define .f
v=1.0
Macro ma(v=2.0)
Debug Pow(v#,v)
EndMacro
ma()
Making it obligatory, the versatility AND readability is bigger. Guarranteed!
Do you see what i mean? :roll:
Else, there is impossible to access to a Global variable inside a Macro if the variable is defined with the same name for the input parameter in the macro.
Posted: Sat Nov 10, 2007 12:11 pm
by freak
You are the only one i have seen putting a # behind every macro parameter.
I think it is a very weird thing to do (as the # is the concatination operator for macros, not a parameter postfix)
I don't think this is a good idea.
Posted: Sat Nov 10, 2007 1:45 pm
by Fred
It's way too ugly ! Don't mess with global var in your macro..
Posted: Sat Nov 10, 2007 4:34 pm
by Psychophanta
Fred wrote:It's way too ugly !
For stuff inside a macro i find not so ugly. :roll:
Fred wrote:Don't mess with global var in your macro..
Ooh!
Mmmmh... ok
for Globals!
But also for constants?
Code: Select all
#var=16.0
Macro ma(var=1)
v.f=1+#var
Debug v
EndMacro
ma()
Posted: Sat Nov 10, 2007 5:42 pm
by Fred
# is already used in the macros to join 2 parameters together.
Posted: Sat Nov 10, 2007 6:41 pm
by Psychophanta
All right, i know, but how to achieve the #var constant inside the macro in the above example?
Posted: Sat Nov 10, 2007 8:07 pm
by Demivec
Code: Select all
#var=16.0
Macro ma(var=1)
v.f=1+#var
Debug v
EndMacro
ma()
Psychophanta wrote:All right, i know, but how to achieve the #var constant inside the macro in the above example?
Since you know #var is a constant that you are referring to in the macro, choose the name of the macro's parameters so they don't match the constant's name. Instead of var choose vari, ,variable, etc. For example, if the constant was named #optionNum, you wouldn't use any parameters called optionNum.
This works:
Code: Select all
#var=16.0
Macro ma(vparam=1)
v.f=1+#var+vparam
Debug v
EndMacro
ma()
Posted: Sat Nov 10, 2007 10:34 pm
by Psychophanta
@Demivec, sincerely that is what is called a limitation of the language, in this case PB language, are not you in accordance?
Simply my request is to avoid limitations as much as posible.
freak wrote:I don't think this is a good idea.
I think it is a worthwhile to think at least twice about it, else think about another strategy to make to be "local" (Protected) to the input variables in a Macro, i.e. to be able to access to external variables and Constants from inside a Macro which has the same names as input parameters.
In Procedures there is different external and local variables, even they have the same name. My purpose is to allow it for Macros too.
Posted: Sat Nov 10, 2007 11:12 pm
by djes
I agree with Psychophanta, there should be a syntax to distinguish macro parameters from others variables declared elsewhere. Or at least there's must be an alert when compiling, or a "good syntax rule" in the doc (naming macro parameters starting with "m_" for example).
The reason is that macro are often used in include files, and you just forget them after a while. I imagine that it could create bugs really difficult to find.
Posted: Sat Nov 10, 2007 11:33 pm
by Demivec
Psychophanta wrote:@Demivec, sincerely that is what is called a limitation of the language, in this case PB language, are not you in accordance?
Simply my request is to avoid limitations as much as posible.
freak wrote:
I don't think this is a good idea.
I think it is a worthwhile to think at least twice about it, else think about another strategy to make to be "local" (Protected) to the input variables in a Macro, i.e. to be able to access to external variables and Constants from inside a Macro which has the same names as input parameters.
In Procedures there is different external and local variables, even they have the same name. My purpose is to allow it for Macros too. Smile
I am in accordance with you that it is a limitation. I am also in accordance with the language limiting it as a way to accomplish something. Limitations are not necessarily bad (but that's another matter ).
In this instance the limitation is that a programmer has to use a parameter name for the macro that doesn't match a declared constant
if the constant is used in the Macro. IMHO this seems minor and nonprohibitive for the various uses of a Macro. Or in otherwords if an individual wanted to use a parameter and constant of the same name in a Macro they are mis-using the tool. Sometimes you can get a screwdriver to function as a hammer and sometimes not, better to use a hammer.
I realize that the limitation that may be the one actually being argued over is one of having the ability to write code that works within the bounds of the language as it currently exists. That is why almost everyone visits/contributes to the forum.
I am all in favor of removing needless limitations but I don't think you will prevail on the points you have expressed. Notwistanding that view, I'll wait and see if you sway Fred or freak.
Posted: Sat Nov 10, 2007 11:48 pm
by freak
I don't see the problem really. It is just like with procedures.
In procedures, if you reuse a global variable (not as a parameter and without protected),
you are referencing the global variable. Same thing happens with macros.
In a procedure, if you reuse the global variable name inside a procedure as a parameter
or with protected, it will not use the global one, and you have actually no more a way
to access the global variable from inside this procedure (as the name represents the local variable then)
The same thing is with macro parameters that have the same name as a variable used elsewhere. makes perfect sense.
You always have to make sure you do not reuse the same name for different purposes.
That is a problem that exists in every language, not just in PB macros.
You can't just name all your global variables "var" and expect to get no conflict.
Choosing descriptive names solves this problem easily.
Posted: Sun Nov 11, 2007 1:05 pm
by djes
it will not use the global one
Said that way, it's OK for me
Don't remember if it's in the doc?
Posted: Tue Nov 11, 2008 1:04 pm
by Psychophanta
I want to use a macro to assign a value to a variable:
It does not work.
That means i am forced to use another variable name different than the macro parameters? YES.
Very bad.
Posted: Tue Nov 11, 2008 6:05 pm
by Little John
freak wrote:That is a problem that exists in every language, not just in PB macros.
You can't just name all your global variables "var" and expect to get no conflict.
Choosing descriptive names solves this problem easily.
I agree.
In this context, I just
have to post a link to an article about
The world's two worst variable names.
Psychophanta, you can easily avoid such conflicts by certain coding habits, e.g. never using a trailing underscore for constant and variable names, and always using a trailing underscore for macro parameters. The following works fine:
Code: Select all
Macro m(a_=200)
a = a_
EndMacro
m()
Debug a
Regards, Little John
Posted: Tue Nov 11, 2008 10:42 pm
by Psychophanta
I know, but you can not refuse the fact that it is a restriction of the language which i think could be avoided. :roll: