Finance | Project Operations, Human Resources, ...

Naming convention local variable in extension class

(0) Share

Report

Posted on by Raphael Bucher

Hello

We are currently discussing internally whether we should add the following rule to our development guideline.
I'd like to know how you guys handle this.

- Local declared variables in CoC-Methods of extension classes must have a prefix/suffix

Assuming you have a base class with a member variable 'str test'.
You make an extension to this class and chain to an existing method. Now inside this CoC-Method, you declare another variable 'str test'.
This does currently not clash with the parents class member variable. There is no compile error, nor is the variable "overriden" in any way through the extension class.
Is it safe to assume this will stay this way? Or could this change and lead to a future compiler error with a platform update

Both variables are addressable through eitherthe local variable name test of the extension class, or through this.test of the base class.

Output:

Do you distinguish your local variable with a (e.g. company-) prefix or suffix?
Im aware of the microsoft docs entry Naming variables and methods added in extension classes, still it does not satisify our internal discussion.

How are you handling this?

Thanks!

I have the same question (0)

All responses (10)

Answers (0)

Suggested answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

Your two variables are local variables in different methods, therefore there's no clash. Your CoC extension is outside the standard method, therefore the local variable of the standard method is not visible to it and there's no clash. The clash can happen if there's a class variable with the same name.

You must use your prefix when adding local variables. Otherwise if MS adds a class variable with same name in upcoming release, your extension would break.

Was this reply helpful? Yes No
Raphael Bucher 97 on at

Like (0)

Report

"Otherwise if MS adds a class variable with same name in upcoming release, your extension would break."

This is exactly what i tried to demonstrate. Take "ClassA_BEC" as a standard class from MS - and "ClassA_B_BEC" from us as ISV.
This is still not breaking - even though there is a class variable declared exactly the same in the standard class as in the CoC Method from the ISV.

You can try this with class from MS aswell - there is no clash nor is it breaking the extension:

This class above is from MS, im extending it and giving a local variable the exact same name as the class variable:

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

Ah, sorry, I missed your first screenshot in your initial message.

I would strongly recommend to follow MS guidelines and avoid these clashes. In my opinion the current behavior is a bug in the compiler, and changes the meaning of the variables which is wrong.

So back to your original question "Is it safe to assume this will stay this way? Or could this change and lead to a future compiler error with a platform update" the answer is No. And I suggest to report this bug to MS. But nice finding!

Was this reply helpful? Yes No
Suggested answer

ergun sahin 8,826 Moderator on at

Like (0)

Report

As we can see from your example, this two are different objects, there is no conflict and I do not think that this structure will change in the future. (Before I saw your example, my thoughts were different,I will examine it in detail when I have time)

But when you use the same name, it becomes difficult to understand. For this reason, although we cannot say that this is a must, it is obvious that using a prefix makes things easier.

Was this reply helpful? Yes No
Raphael Bucher 97 on at

Like (0)

Report

thanks for the input, appreciated! i doubt its a bug, if you think of it as an augumentation to the classes and not an inheritation, why shouldn't extension classes have their own seprate scope of variables.. but yeah only MS can answer that

still, im reading the docs as if they are only talking about member/class variables and not local variables. not sure if i just dont understand it correctly

Was this reply helpful? Yes No
Raphael Bucher 97 on at

Like (0)

Report

[quote user="ergun sahin"]But when you use the same name, it becomes difficult to understand.[/quote]
thanks for the feedback! ofcourse we want to avoid to name the variables the same when they already exist.

but imagine you are extending a validateWrite method, where you usually start with
boolean ret = next validateWrite();

as you probably did in the previous version of AX.. its somewhat tedious to write boolean ret_BEC (assuming we use _BEC suffix to differentiate) and it just looks wrong and i'd even say this looks less readable and doesn't add any value except "maybe" avoid a future clash because of microsoft decides to add a 'ret' variable to the base classes member variable

Was this reply helpful? Yes No
Suggested answer

ergun sahin 8,826 Moderator on at

Like (1)

Report

I'm using prefix, it should be used if you ask my opinion

However, as you mentioned, if the system does not warn when there is a name conflict with the global variable (unless it is just a specific situation for you), it is unlikely to can be fixed, even if it is a bug. Lots of people use coc, I don't think they really check global variables every time. A lot of code will explode in the case of bugfix.

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report
You are right that it's not class inheritance. But the augmentation class can still access the class variables of the augmented class.

And therefore it's strange if the augmentation class can introduce its own variables with conflicting names.

For example, here I have two classes:

class MyClass { str myVariable; void new() { myVariable = "MyClass"; } void printMyVariable() { Info(myVariable); } }

[ExtensionOf(classStr(MyClass))] public final class MyClass_Extension { void printMyVariable() { next printMyVariable(); Info(myVariable); str myVariable = "MyClass_Extension"; Info(myVariable); } }

If we now instantiate MyClass and call printMyVariable method, it will print

myClass myClass myClass_Extension

which is OK. But in my extension class "myVariable" first points to the class variable of the augmented class. But we can still introduce a local variable with the same name!

To me it feels like there's a bug. At least it's strange.

Was this reply helpful? Yes No
Raphael Bucher 97 on at

Like (1)

Report
Alright, I see. This shouldn't be possible.. you can even redeclare the variable to another type (e.g. int)

class MyClass { str myVariable; void new() { myVariable = "MyClass"; } void printMyVariable() { Info(myVariable); } }

[ExtensionOf(classStr(MyClass))] public final class MyClass_Extension { void printMyVariable() { next printMyVariable(); Info(myVariable); int myVariable = 123; Info(any2str(myVariable)); } }

and it compiles

or

class ClassA_BEC { str test; public static void main(Args _args) { ClassA_BEC a = new ClassA_BEC(); a.run(); } public void run() { test = classStr(ClassA_BEC); Info(test); } }

[ExtensionOf(classStr(ClassA_BEC))] final class ClassA_B_BEC_Extension { public void run() { Info(test); int test = 123; Info(any2Str(test)); next run(); } }

and this prints as:

ClassA_BEC 123 (nothing)

Was this reply helpful? Yes No
ergun sahin 8,826 Moderator on at

Like (0)

Report

I also think it's strange.

I wonder, What it will print when we define myvariable in extension but not give it any value.

I also wondered what will do when we define int myvariable, not str.

Was this reply helpful? Yes No