+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: new new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
Would be nice to have this to force names deobfuscation when Rename invalid identifiers
fails at obfuscated names detection.
Maybe rename "Rename invalid identifiers" to "Rename identifiers" and new checkbox "Rename
invalid only" enabled-by-default in the Rename identifiers dialog would be more
"when Rename invalid identifiers fails"
I think rename invalid identifiers should not fail at all.
If it fails, that means there is a bug or it is not implemented very well.
I don't think it is good idea to rename all, why would user need that?
If there are some valid identifiers, it is good to leave them as is.
Actually, my goal is to make renaming invalid identifiers feature working in 100% of
Well, how would you determine such obfuscated names:
"potato", "parrot", "car", etc.?
I know obfuscators renaming identifiers in such manner - so the full rename could help
here since "package_1" and "Class_1" is much better than abstract "parrot" and "car".
hmm, okay, I will consider adding "rename all by type" feature. But personally I will
rather have parrot and car classes, than 100 classes named class_1,class_2...class_255,
because they are easy to distinguish and remember even if they do not have names
suggesting their functionality.
yeah, in my example it could be so, but there could be much more hard to remember
combinations, like sunMoonLightDark, sunLightMoonDark, sunMoonDarkLight. darkMoonSunLight,
I'll be glad to have an option for converting all this names into var_1, var_2, etc.!
I was thinking a little...
There is a problem.
It won't be so easy as it looked like for the first time.
If I rename all identifiers, then all flash built-in packages/classes
(ByteArray,SpriteAsset,...) will be renamed too. I need to somehow detect that name is
built-in and then not rename it.
That is probably easy for class names which have always "flash.*" package,
but what about inherited methods? I have to decide whether a method comes from this class
or is an overriden version of built-in class?
Overriden methods have override flag so I can see that it comes from parent class... but
then I must traverse all ancestors of the class ...
This one is hard so please be patient. I am setting state to "new", but it has low
Thanks for your explanation and no worries - take your time, there is no any urgency for
this issue and I completely understand you have other issues with higher priority for now.
Hope, you'll have some good solution for this built-in names detection, will wait for any
news on this issue!