באג ביצירת פונקציות עם שמות דומים

[gkpln3]

כאשר אני מנסה לייצר שתי יכולות שמיוצגות על ידי אותיות דומות בעברית, אני מקבל התנגשות בשמות, והיכולת האמיתית לא נקראת

קלט:

יכולת סה() {
    בקרה.תעד(״שלום סה״);
}
יכולת ש() {
    בקרה.תעד(״שלום ש״);
}
סה();
ש();

פלט:

שלום ש
שלום ש

[avivcarmis]

@gkpln3 yes your'e right, i've also seen similar complaints on social media. i'll work on it, it's an easy fix, just need to make this dictionary חד חד ערכי.
Obviously, feel free to open a PR if you like to be a contributor ❤️

[eternaleclipse]

That won't solve the core problem - converting directly to English characters will create namespace collisions.
For instance, try creating a variable called ואר.

Or something like:

קבוע א = גטאג
בקרה.תעד(א)

[avivcarmis]

@eternaleclipse yes, that also a valid point. It's possible to try and just leave the Hebrew symbol names as it will still execute.

I'd actually prefer adding additional layer of translation that (after the current one) checks against JS keywords and rename if needed. I.e. today we do ואר -> var which breaks, i suggest ואר -> var -> _var or something of this sort. WDYT?

[eternaleclipse]

I think what you wanna do in this situation is create a simple one-to-one "hash" function.

You can ensure there are no collisions between inputs and other JS variables, by:

• Using a prefix like chvscr_ for Chavascript identifiers to avoid colliding with things like gtag
• Making the dictionary one-to-one, no duplicates and fixed (1 char) length for every value (avoid things like ש = sh)

Btw, your comment has me thinking about how to implement eval (הערך?) support, but that is an entirely different discussion :)

[gkpln3]

You could instead just prefix each name with a constant string, this would prevent the conflict with keywords (as long as you choose a prefix that's not included in any keyword).

Another option is to ditch the type names and just hash the Hebrew string and add a prefix to prevent it outputting a name starting with a number, but this would cause the resulting code to be very unreadalble.

[avivcarmis]

So i opened 2 PRs as 2 possible solutions, originally i preferred the dictionary solution as the result code is much clearer, at this point i'm not sure because some chars cannot be translated 1:1 and still be meaningful. This way i ended up translating ש to o simply because s and c weren't available. If both results produce code this is not clear, i guess i lean towards the hash function as a more robust solution. What do you guys think? Have any favourite? Also feel free to suggest a better char dictionary or a better hash function or anything better, really 😁 @gkpln3 @eternaleclipse

[avivcarmis]

@eternaleclipse

Btw, your comment has me thinking about how to implement eval (הערך?) support, but that is an entirely different discussion :)

Carry on...... 🤔 You have me curious. Or open a new issue for it if you prefer.

[Aminadav]

עוד דוגמא לבעיה

[marmor7]

couldn't open a PR with my fix... so attaching a zipped patch file.

should maintain the same level of readability but prevent name-collisions

alphabet3.diff.zip

[avivcarmis]

@marmor7 I think it's a very cool idea, but since we're trying to avoid Hebrew chars in the output code, i'd also try to avoid any non-ascii char as well. We ended up adopting a combination of the two methods - translating literally for code readability in combination with a simple hash function to enhance uniqueness. We've also added a constant prefix as initially suggested by both @gkpln3 & @eternaleclipse, it's actually not required due to the hash functions but i don't think it decreases readability. The result looks like this:

[avivcarmis]

Thanks to @gkpln3 @eternaleclipse @dorilahav @elisherer @marmor7 for contributing to this discussion, I hope the chosen solution is acceptable to everyone 🙏