![]() (1) What are the known caveats with offering such a feature? Method name collisions between the container type and the element type are one problem that comes to mind (e.g., when I call add on a List do I want to add an element to the list or do I want to add a number to all elements of the list? The argument type should clarify this, but it's something that could get tricky) I have two questions regarding such a proposed feature: The implementation approach would probably be more along the lines of syntactic sugar offered by the compiler rather than by manipulating the actual types ( Stream obviously does not extend BigInteger, and even if it did the "map-add" method would have to return a Stream instead of an Integer, which would be incompatible with most languages' inheritance rules). this would be equivalent to: numbers.map(ONE::add)Īs far as I can tell, the concept would not only apply to "container" types (streams, lists, sets.), but more generally to all functor-like types that have a map method (e.g., optionals, state monads, etc.). Stream numbers = Stream.of(ZERO, ONE, TWO, TEN) ![]() NOTE: BigInteger has an add(BigInteger) method The idea is that working with many elements should not be different from working with a single element: I can apply add(5) to a single number or to a whole list of numbers, and I shouldn't have to write slightly different code for the "one" versus the "many" scenario.įor example (Java pseudo-code): import static .* // ZERO, ONE. One of the features that I am considering for simplifying the use of container types is to make the methods of the container's element type available on the container type itself, basically as a shortcut for invoking a map(. I'm working on a programming language that is supposed to be easy, intuitive, and succinct (yeah, I know, I'm the first person to ever come up with that goal -) ).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |