https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • a
    cause vshaxe just uses api's from the languageserver
  • b
    you could just use regular Haxe syntax highlighting for it
  • b
    as for actual code completion and such... that's a lot harder
  • b
    IMO you're better off just using regular Haxe code if you want IDE support
  • b
    this is an interesting approach in that regard https://github.com/jeremyfa/interpret
  • a
    unrelated: when my hair is that long it basically has the same thickness but doesn't look as good
  • a
    lame
  • h
    Thanks you two!
  • a
    i firmly believe my hair comment was the most helpful
  • b
    My cpp compiles all of a sudden stopped working with HaxeUI...
  • b
    error C2039: '_switch' : is not a member of 'haxe::ui::components::_Switch::Events_obj'
  • b
    Maybe DCE-related
  • b
    Yes, DCE-related
  • b
    I don't think I've ever gotten a compile-time DCE-related error
  • h
    @bright-gpu-74537 It's compiling and working now! Awesome 😄
  • k
    so I'm giving haxeui a go
  • k
    where can I find a demo?
  • k
  • b
    The component-examples repo
  • k
    thanks
  • b
    so this is pretty swish... haxe4 operator overloading: https://try.haxe.org/#8aFf9
  • b
    before i go down the route of any impl, is there any pitfalls someone here might know... any reason to not do this?
  • b
    ah... ok, 
    main.doesntExist;
    doesnt error at compile time now, i could make it error at runtime with an exception or something, but that seems like a pretty huge tradeoff
  • b
    I don't like things like this much. They do improve syntax a bit, but it depends on what's the usage. It's basically hiding the fact that it's dynamic access, like Xml's Fast/Access. If all the content is known at compile time, macros. If not, then if it's not used often 
    comp.get("myId")
    , if it is, 
    comp.myId
    is viable, but only if it's obvious that it's dynamic. And only if there's no other fixed properties.
  • b
    yeah, i think i agree with you... esp the fact that its "hiding" compile errors
  • s
    accessor methods are already commonly used in haxe, so possible dynamic access kind of has to be assumed anyway
  • b
    I wouldn't say commonly. And I definitely won't assume it anywhere.
  • b
    i mean, its fair enough to assume some lib has dynamic access, but certainly not all, and i certainly dont want to introduce it into mine
  • b
    i mean, having 
    <button bob='...' />
    compile is all types of wrong (to me)
  • b
    i could make it error at runtime, ofc, but it just shouldnt have compiled in the firstplace imo
1...888990...1687Latest