Hi,

What is the equivalent of Java's Set interface (as in the HashSet implementation) in Fan? I guess the important bits would be:

• Cost of O(1) for contains()
• No duplications

Thank you, Ophir

Hello liqweed,

Currently we do not have any standard "collections" API bundled with Fan. Although in the case of Set, I personally would just map to keys in a Map (potentially with a dummy value if you don't have one that makes sense). Map.add will throw an exception if the key is already mapped. You can use List also - although contains is a linear scan - so O(n). List.unique will give you a set (it is implemented with a map under the covers to determine uniqueness).

Thanks Brian.

Are there plans to include a collections API? If so, how would it interact with the List and Map literals?

I'd argue that a Set is a very common and useful interface. It probably even deserves some literal notation. Going around the absence of Set (as you suggest) would result in less than pretty code. I can imagine factories producing specific implementations (which would combinations of concurrent/reference/sorted etc.) of the basic collections types (which should be List, Set, Map) given the literals as parameters.

What do you think?

Are there plans to include a collections API? If so, how would it interact with the List and Map literals?

Yes, I'd love to have a Fan module with a nice set of collection utilities. Although I think when it comes to exposing "collections" in a public API, we should try to standardize on List and Func iterators (which we've pretty much done so far already). So I'm not sure we need additional literal syntax - the syntax we have already is pretty powerful - especially the ability to use with-blocks with an implicit call to add:

// this expression
Set { a; b; c }

// is syntax sugar for
temp := Set()
temp.add(a)
temp.add(b)
temp.add(c)

Side note, I still think Set {a, b, c} (requiring commas, and even one trailing comma if needed) is nicer to avoid change of meaning for added methods to the class (such as Set#a). But that's a separate topic and been discussed previously.

yes I agree - we still have that looming problem for the syntax for with-blocks and closures and how they relate to constructors (which I've been guilty of just ignoring)