https://linen.dev logo
Join Discord
Powered by
# lime
  • b
    (that my lib not supporting it because to much macros+abstracts around @struct-anyINIT ;:)
  • a
    but that is where autocomplete shines imo - for code discovery
  • a
    NOT for preventing keystrokes
  • r
    if its about the al parameters in different enums, thats more for structure to be fair, but it could be useful for autocompletion aswell 🤷‍♂️
  • r
    could not agree more
  • r
    now that i think of it making the parameter enum abstracts may not be a smart idea since i want all my things to be hscript compatible
  • b
    💧 maybe my haxecode it also to much 🍝 only
  • r
    and well, you cant access abstracts on hscript!
  • r
    for obvious reasons
  • r
    as in, stuff like FlxColor simply does not exist at runtime, not very fun for what im doing
  • b
    its -> functional <- paradigm-compiler-optimization
  • a
    maybe you just wanna recreate that old perl feeling
  • r
    it is definetly of use yes
  • r
    buuut its not good when you need it at runtime
  • r
    for services like hscript that are executed at runtime
  • b
    definitively not ( i am not would have to write so many simple samples then! )
  • r
    i mean man i got softcoded classes with inheritance and all that working but abstracts?? nah abstracts gotta be special needs
  • b
    yep, thats not OOP-style then anymore!
  • b
    any, into haxe its fascinating (all is possible!)
  • a
    hscript is a different beast for sure
  • b
    hscript is NP -> non-completed
  • a
    that cppia is magic too - but only hxcpp :sad:
  • b
    ( could also be faster! )
  • a
    needs some care
  • b
    needs more -> usecases .)
  • b
    also .. why to make hscript a fully "rewrote"
  • b
    i am think its is good 
    base
    to improve and to build up on!
  • a
    yeah better have a small api in your code for hscript interactions
  • b
    (e.g. like into some libs already)
  • a
    anyway this is getting very offtopic 🙃
1...126127128...138Latest