Wow amazing 😄

I really don't understand why no one has looked into this for a year. It's a pity that so few people have write access

@TracerDS
I didn't put memory addresses into definitions (and don't want to) to keep consistency within the file and with current implementation of similar functions. I don't see any reason to use #define for memory addresses in this case because it will make code messy and review harder.

I will make changes to getters and data types later today. Thank you.
Originally I didn't use const and override to make methods as similar as possible to other methods within the file (again for consistency). It actually looks weird right now after we started to use it in newer PRs without proper refactor of old code.

@TracerDS I didn't put memory addresses into definitions (and don't want to) to keep consistency within the file and with current implementation of similar functions. I don't see any reason to use #define for memory addresses in this case because it will make code messy and review harder.

Magic values are already a hindrance in mta source code. Having them as a definition makes it easier to understand

I will make changes to getters and data types later today. Thank you. Originally I didn't use const and override to make methods as similar as possible to other methods within the file (again for consistency). It actually looks weird right now after we started to use it in newer PRs without proper refactor of old code.

👌

Having them as a definition makes it easier to understand

I actually agree with this and it's useful for reusing address within getter and setter. But it's harder to copy memory address during review / code inspection. And the last one is important since we have PRs without review for years due limited interest / manpower.

But it's harder to copy memory address during review / code inspection.

How so?

How so?

Double click and Ctrl + C is faster and more intuitive than hovering and clicking Copy or switching directly to #define value. The only benefit is that it can be easier to understand in some cases and less risk of using wrong address in multiple places. In this case all addresses are related to method names so we don't really have any problem with understanding what it will change.

Double click and Ctrl + C is faster and more intuitive than hovering and clicking Copy or switching directly to #define value. The only benefit is that it can be easier to understand in some cases and less risk of using wrong address in multiple places. In this case all addresses are related to method names so we don't really have any problem with understanding what it will change.

Thats just laziness that doesnt benefit anyone. Memory addresses dont change, definitions do.

Memory addresses dont change, definitions do.

In our case nothing will really change. This is why it's better to keep it consistent imo.

In our case nothing will really change. This is why it's better to keep it consistent imo.

Thats not consistency. Going with harder to understand codeblocks just because is not a good approach.
Having it defined as a preprocessor variable costs us nothing but benefits exceed the cons.

Magic values are NEVER the way to go

Its better to not create problems that would add up in the future. That way there would be less code refactoring PRs.
Better to make changes earlier while there is still chance for merge

Its better to not create problems that would add up in the future. That way there would be less code refactoring PRs. Better to make changes earlier while there is still chance for merge

I agree with you on this, the only problem with it is that these are not clarified in the community, they are not stipulated in the coding guidelines.

If these were all clarified and prescribed in a format readable by anyone, there would basically be no problem with it - it would be really useful in the case of a new implementation, preventing further refactoring.

I personally think that to avoid future problems it would be worthwhile to use std namespace types, but it takes a lot of people's opinions to decide that, and this PR is not the place for that.

To start with, the coding guidelines haven't been updated for several years. No official documentation is currently up to date regarding the development of the MTA. There is no one who would take care of it and develop it at the appropriate level. Arguing now on every PR will not solve this problem. We should seriously consider developing coding guidelines and establishing some clear community standards.

To start with, the coding guidelines haven't been updated for several years. No official documentation is currently up to date regarding the development of the MTA. There is no one who would take care of it and develop it at the appropriate level. Arguing now on every PR will not solve this problem. We should seriously consider developing coding guidelines and establishing some clear community standards.

It's true. This is why in all my PRs I prefer to make code consistent with existing codebase even when it's not really good in some cases. Without proper refactor many things look out of place.

If someone is interested in merging this for testing in nightly, I will add information to wiki within several hours.

Resolve conversations, please 😃