Issue 635 - Option for std - haxe

[issuesbot]

[Google Issue #635 : https://code.google.com/p/haxe/issues/detail?id=635] by simon.kr...@simn.de, at 25/01/2012, 18:58:28 The haxe std should provide some more basic data structures, the most prominent one being Option:

enum Option<T>

{
    None;
    Some(value:T);
    }

[issuesbot]

[comment from ncanna...@gmail.com, published at 26/01/2012, 03:02:03] I don't want to have the toplevel namespace contain too much types.

Would that work if we put this (and maybe others) into a haxe.lambda package ? (or another name)

[issuesbot]

[comment from heinz.ho...@googlemail.com, published at 26/01/2012, 04:04:12] that's fine, please don't add more toplevel types, we have already typedef functionality for everyone who need it as a toplevel type.

[issuesbot]

[comment from simon.kr...@simn.de, published at 26/01/2012, 09:54:59] Option is not really Lambda related, although often used in that context. Quite a few people like to use is as return type for arbitrary library functions, because it nicely combines has- and get-functionality into a single get call and avoids throwing exceptions and returning null values.

I understand it's a hard decision where to put a type like this, but this is a really fundamental one. It's rather pointless designing functions to return an Option, when the user has to import some lambda (or something else) package for the mere purpose of making "case None:" compile.

If you don't want to make this top level, there's only one solution: an official stdext haxelib that lib authors can rely on. Note the official part as this will not work if some random community member initializes it. It needs the same strict quality and necessity reviewing as the real std, i.e. by you, only with a more lenient attitude towards inclusion of types at top level. Then everyone has the choice of polluting their top level with more types, which I reckon is what this is all about.

What do you think?

[issuesbot]

[comment from simon.kr...@simn.de, published at 26/01/2012, 10:48:54] Also, this stdext lib should be allowed to define a StdTypes.hx which is handled in the same way as the real StdTypes, i.e. automatically included everywhere. This would greatly improve extension experience, e.g. you can use None/Some of the Option right away when using -lib stdext.

[issuesbot]

[comment from ncanna...@gmail.com, published at 26/01/2012, 14:08:35] When I was asked about adding Option on the mailing list I indeed answered that the best would be for the community to organize themselves to setup such a common library, which would be better than isolate it into some package.

I still think it's better this way, since it will save my time for compiler work :)

I'm marking the issue as WontFix then.

[issuesbot]

[comment from simon.kr...@simn.de, published at 26/01/2012, 14:37:39] I'm not asking you to maintain that library, only to bless it with the stamp of "officially supported" and quickly review changes made to it (by the community), so it will remain a high quality lib and not turn into a convoluted mess people don't want to use.

Such a lib would in my opinion need your patronage, even if that consists only of writing "N.C. approved" on the project page. Could I add you as contributor if I create http://code.google.com/p/haxestdext/? That should be sufficient to indicate it's not some solo attempt by me, but a serious move towards an extended std lib. I will then take it from there and address the community about it.