Skip to content

Commit

Permalink
readme lite update
Browse files Browse the repository at this point in the history
  • Loading branch information
@Glidias
Glidias committed Dec 31, 2016
1 parent 7d57781 commit dd92246
Showing 1 changed file with 1 addition and 3 deletions.
4 changes: 1 addition & 3 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -35,9 +35,7 @@ _____

Phase 2 (Lite version to replace existing one):

https://haxe.org/manual/types-abstract.html

Recently, i've discovered more about the power behind Haxe abstracts and macros, and how they can be used instead of Haxe-oriented base classes, RTTI, and metadata, which can bloat your codebase (and adds framework classes with an additional runtime-initialization conversion process) which isn't suitable for small projects. I intend to redo a lightweight version of HaxeVX for VueJS (and hopefully for Vuex as well) using ONLY pure Haxe abstracts and compile-time macros to link directly to VueJS externs. This gives you class-like functionality with Haxe abstracts and all the typical strict-typing/compile-time checkings done when coding VueJS components. This means no additional boiler-framework code will be required beyond your implementation code.
Recently, i've discovered more about the power behind Haxe ~~~abstracts?~~~ and macros, and how they can be used instead of Haxe-oriented base classes, RTTI, and metadata, which can bloat your codebase (and adds framework classes with an additional runtime-initialization conversion process) which isn't suitable for small projects. I intend to redo a lightweight version of HaxeVX for VueJS (and hopefully for Vuex as well) depending ONLY ~~~pure Haxe abstracts and~~~ compile-time macros to link directly to VueJS externs. This gives you class-like functionality ~~~with Haxe abstracts~~~ and all the typical strict-typing/compile-time checkings done when coding VueJS components. This means no additional boiler-framework code will be required beyond your implementation code. (Note: abstracts vs classes is still under consideration, as there some advantages/disadvantages between using either of them for Vue.)

This comment has been minimized.

Sign in to view

Copy link
@francescoagati

francescoagati Dec 31, 2016

classes are better of abstracts for some type of metaprogramming:
you can add more functionality with interfaces that injects macros functionality. abstracts can't implement interface.
(https://haxe.org/manual/macro-auto-build.html)

This comment has been minimized.

Sign in to view

Copy link
@Glidias

Glidias Jan 1, 2017 •
edited
Loading

Author Owner

Yes, I tried abstracts and it only appears useful in certain cases (eg. proxying to a data structure such as Immutable map/record to provide type-safe data access ( eg. doodles here ). You can still inject macro functionality with @:build metadata, but you lose a lot of the OO functionality with @:autoBuild and typical OO extending/implementing features you mentioned. Additionally, a class may implement multiple interfaces that may add-on multiple macro modules/functionalities.

Also, for Vue, the way it handles "this" is particularly "non-standard", so there are various issues with macro-resolving "this" identity within abstract methods (which are ACTUALLY static methods that I had to try and macro-hack the expressions within to defuse the "this1" function parameter references back to regular js "this") and i had to give up entirely due to additional side-effects/lack theereof with compile checks. Overall, the class-based approach works (as intended) right now. It's only that the entire _toNative() runtime implementation should be done via Macros instead. It's my first time trying out Macros in Haxe (and they are very powerful indeed, not just in generating code, but also being able to modify compile behaviour/perform additional custom syntax checks, etc. at compile-time..). Once _toNative conversion is replaced with macro code, Vue component classes should work right off the bat upon instantiation.

Generally, some modifications/optimizations to the existing codebase would be fine without needing any overhaul, so i created an official roadmap here for the needed changes in the Issues section. With additional macroing, having to extend VComponent should become an optional dependency as well.

This comment has been minimized.

Sign in to view

Copy link
@francescoagati

francescoagati Jan 1, 2017

you can see an example how i have impletmented a component riot.hx in a haxe class https://github.com/francescoagati/riot.hx/blob/master/src/riot/RiotBuilder.hx. but the code is really old and can be implemented really better.

in general with vue.js 2 components and haxe macro you can simply take the instance methods of the class and rebinds this methods with the prop methods of the vue component. in this mode the 'this' at runtime will be added directly to the instance of the component

This comment has been minimized.

Sign in to view

Copy link
@francescoagati

francescoagati Jan 1, 2017

this is a stupid example for bind class instance methods with vue compoent methods property
http://try-haxe.mrcdk.com/#c1BDc

This comment has been minimized.

Sign in to view

Copy link
@francescoagati

francescoagati Jan 1, 2017

see the js source of the compiled javascript

This comment has been minimized.

Sign in to view

Copy link
@Glidias

Glidias Jan 2, 2017 •
edited
Loading

Author Owner

Yup. Anyway, as a correction: self should be further set as self = untyped self.prototype; . I'm already doing something like that at runtime (via reflection atm), and intend to convert it similarly via a macro with lines like untyped this.methods=ObjDecl, untyped this.props=ObjDecl, untyped this.computed=ObjDecl , etc. that I intend to execute at the end of the constructor body of the class. I basically scan through the class properties to form up the relavant ObjDecl to set into the existing instance.

The Static initialization __init__ overwrite for global components is particularly interesting (didn't knew about it), and I might consider that approach as well instead of constructor-based instantiation and external new Vue(optsInstance) Vue.component(id, optsInstance) setups (albeit the latter is more flexible).

If you need a guide of what features are already available in HaxeVx, you can check out the wiki guide:
https://github.com/Glidias/haxevx/wiki/Vue---HaxeVX-Draft-version-guide

This comment has been minimized.

Sign in to view

Copy link
@francescoagati

francescoagati Jan 2, 2017

yes thanks i have write really fast the example. init is a good options. haxe has many features for create js code
______

Expand Down

0 comments on commit dd92246

Please sign in to comment.