Closed waneck closed 11 years ago
[comment from si...@haxe.org, published at 2013-01-26T14:16:47.000Z]
[comment from ncanna...@gmail.com, published at 2013-02-02T11:30:47.000Z] 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.
[comment from si...@haxe.org, published at 2013-02-02T18:16:55.000Z] I still think this would go really well with operator overloading to easily define wrapper types.
[comment from polysema...@gmail.com, published at 2013-02-04T08:58:12.000Z] 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.
[comment from ncanna...@gmail.com, published at 2013-02-04T09:38:28.000Z] You should be able to generate appropriate code with macros.
[Google Issue #1412 : http://code.google.com/haxe/issues/detail?id=1412] by si...@haxe.org, at 2013-01-24T15:12:20.000Z 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.