https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • h
    Essentially just make the macro define a contract for a static function signature with the custom component where it will be used in place of the normal new usage. If someone doesn't implement that then they don't intend on their component being usable from XML
  • b
    im not really a huge fan of that, the idea is that it super easy to use components from xml... you shouldnt need to wire up anything
  • b
    > don't intend on their component being usable from XML
  • b
    i also think that the dev cant really make that distinction
  • b
    and this error is nothing to do with that anyway, this is what is happening essentially:
  • b
    Copy code
    haxe
class MyComponent extends Box {
    public function new(someparam:String) {
        super();
    }
    
    // macro generates something like:
    public function clone():MyComponent {
        var c = new MyComponent(); // <---- this errors
        return c;
    }
}
  • h
    The XML imposes a fundamental constraint on the design of someone's custom component in that we can't force properties to be non optional
  • h
    Therefore forcing us to rely on default values and look for hooks on creation to start working with our expected parameters
  • b
    well, then you could have constructor params and just not use the xml if the above wasnt the case, but the above has zero to with using xml
  • b
    if the above is fixed, then you can use non default constuctor params and if you tried to use from xml you would just get an error
  • h
    That's where creating that creation based contract I mentioned comes in
  • h
    It can be used instead of that
  • h
    Dart has factory methods which would be perfect for this
  • b
    yeah, but as i said, i dont like the idea of forcing a control to be "im allowing this for xml"... thats not the idea here
  • b
    but anyway, thats nothing to do with this anyway
  • h
    Well, the problem comes down to a pattern by interface - and right now there's a limitation on construction
  • h
    Right?
  • b
    if you want to use components without xml, and with constructor params, then fine (assuming this bug above didnt exist) do so, if you want to use components from xml, they have to be able to be "new()"d
  • b
    the bug above is totally seperate to the xml, its the built .clone() function
  • h
    Gotcha - I'm coming from a different perspective on it here but exactly the same issue. So currently clone expects a constructor without new as well. So there's a common interface haxeui uses where it'll construct and then fill by name. That sounds like a good case for hooking into a method after those have been filled out - haven't looked for one though...
  • h
    Still, it seems like the framework claims your constructor as is, and definitely if you do choose to utilize XML... Which you are saying is by choice
  • b
    well, clone creates a new instance of the class its in, and that uses 
    new $typePath();
    in the macro, however, if you have non default constructor params then that aint gonna work (as it doesnt)... so its easy enough to do something like 
    new $typePath(p1, p2, p3);
    i can find out the name and type of those params from the constructor... what i dont know is what values p1,p2, etc should hold
  • b
    because it maybe that you do something like:
  • b
    Copy code
    haxe
class MyComponent extends Box {
    var bob:String;
    public function new(someparam:String) {
        super();
        this.bob = someparam;
    }
}
  • b
    so i cant rely on it being 
    this.someparam
    , and in fact, i cant even say that you just ignore that param altogether
  • b
    also, if i kept track of it by adding a var 
    ____someparam
    (for example), then i cant say that that param hasnt changed either when it comes to clone
  • b
    arguably these are edge cases, but still
  • b
    > Still, it seems like the framework claims your constructor as is, and definitely if you do choose to utilize XML... Which you are saying is by choice I really dont follow, there are two things: 1. you cant have a non default constructor, at all, because a bug in the macro is trying to new your component with no params and it is expecting some. This is a bug and should be fixed, the framework is erroronously making an assumption that is limiting and invalid 2. you cant have a non default constructor if you want to use a component from xml because its expecting to "new()" it also, this however is fine because there is no facility to pass constructor arguments to a component via xml
  • b
    so if you dont want to use, or care, about your component being used from xml with constructor params fine, just leave it as is - it wont work yet because of #1 above, if however you do want to use your component from xml, then you have to obide by the "contract" which is "params as fine, but they have to be defaultable"
  • b
    unless we come up with a method of passing params to a constructor via xml, thats also a solution, but again, none of this is to do with #1 above which is a bug, assumption, oversight
1...332333334...1687Latest