Onsite getters and setters implementation

[posxposy]

Add a way to implement getters and setters directly in the place where they are declared. At least for simple (one line) expressions.

Example:

public var isDataExists(() -> data != null, never):Bool;

Rendered version

Thanks!

[RealyUniqueName]

This could be handy especially for abstracts.

What would be the syntax to override such getters/setters in child classes?

[posxposy]

What would be the syntax to override such getters/setters in child classes?

Haxe compiler may parse this short expression: () -> data != null just into regular syntax:

function get_isDataExists():Bool {
    return data != null;
}

So, get_isDataExist will be allowed for overriding by the child.

Alternatively, it may be parsed as final or inline get\set function so it cannot be overridden by child entities.

[Gama11]

This looks pretty much exactly like https://github.com/HaxeFoundation/haxe/pull/7129.

What would be the syntax to override such getters/setters in child classes?

...and bringing up override syntax is one of the things that made @simn reconsider.

[posxposy]

This looks pretty much exactly like HaxeFoundation/haxe#7129.

Uh oh, never seen this before.

But, I've added notes about overriding in drawbacks section.

[nadako]

I wanted something like this for a long time, but I can't shake of the feeling that what was proposed so far is not very useful in practice...

E.g. in the mentioned case of abstract properties, most often it's about fancy field forwarding which you want to be inline, but this proposal doesn't seem to support defining inline accessors, which makes it less useful.

[RealyUniqueName]

Maybe such syntax should imply inline, which kind of solves the design for overriding.

[RealyUniqueName]

But that doesn't sound very obvious...

[posxposy]

Haxe allows as to use inline keyword on static variables. Why not allow it for variables with access modifiers as well?

//will be inlined both(get and set), cannot be overriden:
public inline var isDataExists(() -> data != null, never):Bool;

//Not inlined, can be overriden:
public var isDataExists(() -> data != null, never):Bool;

And for full syntax:

//will be inlined both(get and set), cannot be overriden:
public inline var isDataExists(get, never):Bool;
function get_isDataExists():Bool { // inline
    return data != null;
}

//Which is the same as:
public var isDataExists(get, never):Bool;
inline function get_isDataExists():Bool {
    return data != null;
}

[ncannasse]

I don't think we should accept things that are just syntactic sugar and complexify the language while not bringing any new actual feature, especially if the main goal is just to save a function declaration.

[nadako]

I tend to agree with Nic. At the same time I wouldn't be opposed to a shorter getter/setter definition, but I think that trying to shove accessor functions betwee name and type won't work. If anything, we could maybe think about "proper" syntax, something along these lines:

var prop:Int {
    inline get: _prop, // generates `inline get_prop():Int return _prop`
    override set: _prop = value // generates `override set_prop(value:Int):Int return _prop = value`
};

[kLabz]

+1 for C#-like properties like nadako described, which can be used with blocks too (just to keep things in the same place).

As for access control, we can use private, inline, override on get / set

[Simn]

FWIW I'm also in favor of C#-like properties.

[Simn]

We didn't reach a consensus on this one in our haxe-evolution meeting yesterday.

We mostly agreed that something like this would be good, but it's unclear if it should work exactly as presented here.

[RblSb]

Not sure if there is support for context-restricted keywords, but i would like some alternative syntax like that:

// alternative to current proposal:
// public var isDataExists(() -> data != null, never):Bool;
public get isDataExists() data != null;

// alternative to:
// var self(get, never):MyAbstract;
// inline function get_self() return cast(this, MyAbstract);
inline get self() cast(this, MyAbstract);

// alternative to:
// public var value(null, set) = 5;
// function set_value(v) value = v;
var _value = 5;
public set value(v) _value = v;

This is not cool one-liner and misses "Physical field" feature of current syntax (same as C#-like properties?), but probably feels less verbose and easier to remember.

[Simn]

lean-reject: proposal too weak, feature itself might be valid but needs more thought and design

[Simn]

We have rejected the proposal in the haxe-evolution meeting today.

While we agree that a shorthand syntax for properties would be nice, we don't think the proposed one is ideal. There was general agreement among the team that something like the C# property syntax would be better. A proposal which aims to support this would appear to have a high likelihood of being accepted.