HaxeFoundation / haxe

Haxe - The Cross-Platform Toolkit
https://haxe.org
6.09k stars 646 forks source link

Issue 1412 - Abstract access to fields of underlying type - haxe #1412

Closed waneck closed 11 years ago

waneck commented 11 years ago

[Google Issue #1412 : https://code.google.com/p/haxe/issues/detail?id=1412] by si...@haxe.org, at 24/01/2013, 15:12:20 The attached patch allows specifying which fields of the underlying type might be accessed directly on the abstract.

The used syntax is: abstract Name(Type with *) abstract Name(Type with (field name list)) abstract Name(Type without (field name list))

I'm not particularly adamant about this specific syntax, but I think it's quite descriptive. Here's an usage example: https://gist.github.com/6fb9e9c8eb7a5b66279b

I think this feature (in whatever syntactic form) is required in order to make abstracts usable. Otherwise re-declaring each field in the abstract is overly tedious.

Please comment/review/accept.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 26/01/2013, 14:16:47]

waneck commented 11 years ago

[comment from ncanna...@gmail.com, published at 02/02/2013, 11:30:47] I'm not in favor of having abstracts as restrictions/subsets of existing classes. This somehow overlap with structures while being less flexible.

Most of the time, the abstract API will be quite different from the underlying type one, or have a different semantic. Having the user think about his abstract API and write the corresponding code correspond more to the abstract usage I wish to promote.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 02/02/2013, 18:16:55] I still think this would go really well with operator overloading to easily define wrapper types.

waneck commented 11 years ago

[comment from polysema...@gmail.com, published at 04/02/2013, 08:58:12] I'm doing StateArrows in node (to hide the Future monad: (A->Future) -> Arrow<A,B>), and it's going to be a pita to redefine combinators each time. Much of the time arrows share the same base class / function signature, but can't really be considered a subtype, and allocations (new ArrowChoice(arr/Arrow<A,B>/)) would be inefficient. Tinkerbell's syntactic delegation is pretty sweet.

waneck commented 11 years ago

[comment from ncanna...@gmail.com, published at 04/02/2013, 09:38:28] You should be able to generate appropriate code with macros.