New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add proposal "0000-polymorphic-this-types" #36

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@matulkum
Copy link

matulkum commented Nov 14, 2017

@nadako

This comment has been minimized.

Copy link
Member

nadako commented Nov 14, 2017

I added a link to the rendered version so one can easily view the proposal markdown document.

@EricBishton

This comment has been minimized.

Copy link
Member

EricBishton commented Nov 14, 2017

As a first thought, isn't this what static extensions are supposed to solve? Why would that mechanism be insufficient? (https://try.haxe.org/#01b82)

using Test.Calculator;

class BasicCalculator {
    public var result = 0.0;

    public function new () {}

    public function add(a: Int): BasicCalculator {
        result += a;
        return this;
    }
}

class Calculator {
    public static function sin(c:BasicCalculator): BasicCalculator {
        c.result = Math.sin(c.result);
        return c; 
    }
}

class Test {
    static function main() {
        var calculator = new BasicCalculator();
        var result = calculator.add(2).add(3).sin().result; // <-- Totally possible in current Haxe
    }
}
@matulkum

This comment has been minimized.

Copy link

matulkum commented Nov 14, 2017

@EricBishton I agree that you solved this specific example with a static extensions. In general it is not the same though: you cannot override a method in BasicCalculator. You can also just add methods, not properties. You could not extend BasicCalculator with a static extension like in this example:

enum Mode {
   RAD;
   DEG;
}
class Calculator extends BasicCalculator {
    public var mode: Mode; 
    
    public function sin() {
        if( this.mode == RAD)
	    this.result = Math.sin(this.result);
        else
            this.result = Math.sin(this.result/180*Math.PI);
        return this;       
    }
}

class Test {
    static function main() {
        var calculator = new Calculator();
        calculator.mode = DEG;
        var result = calculator.add(2).add(3).sin().result;
    }
}

Also static Extensions do not help in creating Extern definitions.

@matulkum
Copy link

matulkum left a comment

fixed 2 little bugs in the code examples.

@markknol

This comment has been minimized.

Copy link
Member

markknol commented Nov 14, 2017

I wonder if this should be a type inference feature, if you leave out the return type definition, it works? Then this stays the same in its context, just as we have now.

@matulkum

This comment has been minimized.

Copy link

matulkum commented Nov 14, 2017

@markknol Actually we do NOT have that now. Currently the return type BasicCalculator.add() will infer to BasicCalculator always, even if it is called from Calculator.. and I think rightly so.

By providing this as an option to implicitly define the return type you can have it both ways and you have actual control. See also @nadako comment at the community forum: http://community.haxe.org/t/feature-proposal-polymorphic-this-types/174/5

@markknol

This comment has been minimized.

Copy link
Member

markknol commented Nov 15, 2017

Just want to mention that @andyli once wrote this very nice article:
https://blog.onthewings.net/2010/12/19/method-chaining-and-fluent-interface-in-haxe/

But I'd love to have polymorphic this type too, I use a lot of chaining too.

@matulkum

This comment has been minimized.

Copy link

matulkum commented Nov 15, 2017

@markknol thanks for the link. Did not even see that before. So this is actually a pretty "ok" workaround for this case.

@EricBishton

This comment has been minimized.

Copy link
Member

EricBishton commented Nov 15, 2017

@markknol @andyli Perhaps, if Andy gives permission, a version of his article could make it into the Haxe cookbook on the web site (with appropriate attribution).

@andyli

This comment has been minimized.

Copy link
Member

andyli commented Nov 16, 2017

Feel free to take it to the cookbook. I'm glad that little post is still useful. :)

@skial skial referenced this pull request Nov 16, 2017

Closed

Haxe Roundup 408 #450

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Nov 23, 2017

I'd like to also be able to do this:

class Some {
  static function doSomething():this {
    var inst = new this();
    return inst;
  }

  static function doAnotherThing():Class<this> {
    return this;
  }
}

Which will allow to:

  • Reduce amount of work on renaming types
  • Simplify macros which need to operate with current type
  • Simplify copy-pasting (bad side effect :) )

Maybe make it a reserved class name This instead of this.

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 21, 2018

We discussed this proposal and came to a conclusion it could be useful. However, @Simn has no clear vision how to implement it and needs to do a research first.
As for my previous comment about using This as the type expression, it should be a separate proposal.

@Geokureli Geokureli referenced this pull request Nov 15, 2018

Closed

Suggestion: multiple FlxVector changes #2185

0 of 3 tasks complete
@fullofcaffeine

This comment has been minimized.

Copy link

fullofcaffeine commented Dec 5, 2018

Just want to mention that @andyli once wrote this very nice article:
https://blog.onthewings.net/2010/12/19/method-chaining-and-fluent-interface-in-haxe/

But I'd love to have polymorphic this type too, I use a lot of chaining too.

The link is dead. Did anyone ever add this to the cookbook? I couldn't find anything related.

@markknol

This comment has been minimized.

Copy link
Member

markknol commented Dec 6, 2018

@fullofcaffeine the site is up again, please PR it for the cookbook 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment