Completely remove support for specifying getter/setter method name in a property declaration

[nadako]

Currently, Haxe supports var a(get_a, set_a) along with a(get,set). I guess it was supported to ease transtion from haXe 2, however it's been years and nowadays it only creates confusion, ambiguity and annoyance/issues when working with untyped AST.

So shouldn't we forbid that? I understand that this is a breaking change, so we may want to output a warning for one or two releases and then change it into a proper error.

[ncannasse]

Could you explain how it causes problem for you?

[Simn]

It's annoying for refactoring.

[nadako]

Well, the reason I created this issue is that I just had to explain to people that get_<propname> syntax is a leftover from Haxe 2 days, and they can't write var a(getSomeA,...), also I believe if someone wants to write a macro that works with haxe.macro.FieldType.FProp, he has to consider both "get" and "get_" + field.name which is just an annoyance for no obvious reason.

[Simn]

Let's deprecate this for Haxe 4 and remove for 4.1.

[RealyUniqueName]

Isn't it already deprecated since Haxe 3?

[Simn]

It didn't print deprecation warnings in Haxe 3. But I'm actually willing to just break it for Haxe 4 with an appropriate error message.

[ncannasse]

I'm fine with break in Haxe 4

…

On Thu, Apr 19, 2018 at 10:10 AM, Simon Krajewski ***@***.***> wrote: It didn't print deprecation warnings in Haxe 3. But I'm actually willing to just break it for Haxe 4 with an appropriate error message. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4699 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwIDcLSRWl4x4ijdwEyfcnI9fhcUKks5tqEZogaJpZM4GuL4-> .

[mastef]

I don't think it's cool to outright break it. I know of projects that use this, and we use it also in multiple projects. Depreciate first with warning messages... allow people for a transition period instead of breaking everything at once.

[mastef]

And/or: provide macro that would re-enable this feature to work for abandoned legacy projects other projects rely on...

I don't see how it's necessary to add such a major breaking change so rapidly. There's no benefit except adding more workload on people working with the latest haxe version for no reason.

[SavedByZero]

I agree, I am NOT a fan of this change. I use a proprietary engine that just upgraded its haxe version from 3.4 to 4.1, and now my code is completely broken because of this.

[nadako]

The fix should be just a simple regex find/replace though, isn't it?

[mastef]

The fix should be just a simple regex find/replace though, isn't it?

That's never the case. Then you have dependent libraries, etc.

[SavedByZero]

Not with hundreds of functions with unique names of get/set_{whatever}. And not when the project is in a code locked, data-updates-only phase (which still sometimes requires compilation for app store versions). Doing such a sweeping find/replace would be extremely risky, however theoretically sound it seems.

[Simn]

You're transitioning across a major compiler version in a code locked project?

I acknowledge that it was a bit sloppy to not have deprecation warnings in Haxe 3, but it's not like this would have changed much because you still would have to make the changes the same way. Also, there's no point in complaining about this now because we're not going to bring the old syntax back.

Maybe we can provide a regular expression for this. Haxe's property syntax is so unique that it should be quite straightforward and avoid any false positives.

[SavedByZero]

Yeah, it’s one of those cases where it’s not what I want, it’s what he-he-he (the client) wants. I suppose a regular expression from the Haxe crew themselves, that works without breaking anything would help. I could Ctrl-z worst case.

…

Sent from my iPhone

On Dec 23, 2020, at 12:09 PM, Simon Krajewski ***@***.***> wrote:  You're transitioning across a major compiler version in a code locked project? I acknowledge that it was a bit sloppy to not have deprecation warnings in Haxe 3, but it's not like this would have changed much because you still would have to make the changes the same way. Also, there's no point in complaining about this now because we're not going to bring the old syntax back. Maybe we can provide a regular expression for this. Haxe's property syntax is so unique that it should be quite straightforward and avoid any false positives. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[nadako]

Something like this maybe?

(var\s+(\w+)\s*\(\s*)(?:(get)_\2|(\w+))(\s*,\s*)(?:(set)_\2|(\w+))(\s*\))

replace string:

$1$3$4$5$6$7$8

[back2dos]

Here's a build macro to get custom accessors to compile with deprecation warnings:

import haxe.macro.*;

class Haxe3Properties {
  static function support() {
    var ret = Context.getBuildFields(),
        found = false;

    for (f in ret)
      switch f.kind {
        case FProp(get, set, t, e):
          var oldGet = get == 'get_${f.name}',
              oldSet = set == 'set_${f.name}';

          var old = oldGet || oldSet;
          if (old) {
            found = true;
            var used = [],
                expected = [];
            if (oldGet) {
              used.push(get);
              expected.push(get = 'get');
            }
            if (oldSet) {
              used.push(set);
              expected.push(set = 'set');
            }
            Context.warning('Using ${used.join(" and ")} is no longer supported. Use ${expected.join(" and ")} instead.', f.pos);
            f.kind = FProp(get, set, t, e);
          }
        default:
      }

    return
      if (found) ret;
      else null;
  }
}

You can apply this to a whole build with --macro addGlobalMetadata('','@:build(Haxe3Properties.support())') - or better yet only apply it to packages that really need it, to reduce impact on compilation speed).