Just discovered Fan the other day and been reading through the language docs. There are some very nice features here, and in particular the ability to run on .NET or JVM - as a CTO this spells "double my market". So well done.
I've got a couple of suggestions though.
The first revolves around the List.slice method, which returns a copy of that range of the original List.The ability to return a "view" of that list, where changes to the view are reflected in the parent, would be very useful. My model for this is java.util.List.subList and java.nio.ByteBuffer.slice.
Use cases are pretty obvious but just in case: imagine an array of points specified as [x1, y1, x2, y2, ... xn, yn]. If I want to alter a sequence of these I need to pass in the list, offset and length.
It would be cleaner and less prone to error to do something like process(mylist.view([2..7])) rather than process(mylist, 2, 5)). Index out of bounds checking can be done, I don't have to add offsets to everything... frankly it's an all-round win.
Cheers... Mike
brianFri 4 Sep 2009
Hi Mike,
Thanks for the suggestion, we have actually talked about this before a bit. It would definitely be useful, but at the same time once you start programming in Fan you find that you often only mutate lists internal to your class and use immutable lists in publicly exposed APIs. So passing mutable lists is almost an anti-pattern. Also see previous discussion #580.
However, I would consider the idea of slicing / viewing / listening to mutable lists an open issue. The way I am framing these sort problems in my mind is LINQ-to-Events. It is amazingly elegant way to unify collections, iterations, and change events.
mikeb Fri 4 Sep 2009
Hi there
Just discovered Fan the other day and been reading through the language docs. There are some very nice features here, and in particular the ability to run on .NET or JVM - as a CTO this spells "double my market". So well done.
I've got a couple of suggestions though.
The first revolves around the List.slice method, which returns a copy of that range of the original List.The ability to return a "view" of that list, where changes to the view are reflected in the parent, would be very useful. My model for this is java.util.List.subList and java.nio.ByteBuffer.slice.
Use cases are pretty obvious but just in case: imagine an array of points specified as
[x1, y1, x2, y2, ... xn, yn]. If I want to alter a sequence of these I need to pass in the list, offset and length.It would be cleaner and less prone to error to do something like
process(mylist.view([2..7]))rather thanprocess(mylist, 2, 5)). Index out of bounds checking can be done, I don't have to add offsets to everything... frankly it's an all-round win.Cheers... Mike
brian Fri 4 Sep 2009
Hi Mike,
Thanks for the suggestion, we have actually talked about this before a bit. It would definitely be useful, but at the same time once you start programming in Fan you find that you often only mutate lists internal to your class and use immutable lists in publicly exposed APIs. So passing mutable lists is almost an anti-pattern. Also see previous discussion #580.
However, I would consider the idea of slicing / viewing / listening to mutable lists an open issue. The way I am framing these sort problems in my mind is LINQ-to-Events. It is amazingly elegant way to unify collections, iterations, and change events.