Nice TWiki > Dev > NiceDiscussions? > StandardLibrary (r1.3) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
The standard library needs work. One area is the collection hierarchy. There are so far few implementations. It is a question whether to add new ones, or make java.uil.* collections part of it, with polymorphic types. Something to look at could be how GJ retrofits polymorphic types on java.util. Would it be legal, techinacally possible and good to resuse this work, more or less automatically? There has been some discussions with BrynKeller about this subject.

I think that implementing the import of java.util.Collection and friends might be made easier by some change in the compiler, so I suggest to wait about that part, I will have a look.

-- DanielBonniot - 31 Jul 2002

I've noticed that there's a need for another basic method on Collection, which is a method that's like foreach, but provides the client code with some way to stop the iteration. I'll call this method forbreak, because it's foreach with a break. It looks something like this:

<Any T> void forbreak(Collection<T> coll, (()->void)->T->void func);

forbreak(s@Sequence, func) {
  boolean breakFlag = false;
  T->void each = func(()->void esc =>{breakFlag = true;});
  for(int i=0;!breakFlag; i++) {
So the function passed to forbreak takes an 'escape continuation', so-to-speak, and returns a function to iterate with. Then the iterator function can use the escape continuation to break off the iteration when desired. Foreach can be implemented trivially on top of forbreak:
foreach(c@Collection, func) = c.forbreak(()->void esc=>func);
and it seems like a more generally useful building block for functions on collections which may or may not be sequences, or support size(), or what have you. For instance, find() is currently defined on Sequence, but with forbreak installed, it could be promoted up to Collection. If we added a method mkEmpty, which would produce an empty collection (i.e., much like a no-args constructor) to Container, then we could define foldLeft, map, filter, etc. top of forbreak. So for collections to get all that great functionality, they only have to define mkEmpty and forbreak. Actually, mkEmpty plus either forbreak or fold would do. Maybe we should make fold the base operation, and forbreak can easily be built on that as well.

Another thing I've been struggling with, is that the current collection hierarchy is somewhat imprecise - Collection specifies a number of operations which commonly appear together, but which might not always be appropriate (e.g., it's debatable whether LazyVector? should have a size method), and the same is true of sequence. I'm toying with a much more granular hierarchy at the moment, which I'll detail later. It also has two hierarchies, one for collections which allow in-place modification, and one for collections which do 'functional update', that is, return copies of themselves with the changed values. More later. -- BrynKeller - 05 Aug 2002

Generic Java There is a new version of the Nice compiler that understands Generic Java type signatures. This allows in particular to use java.util.* collections with parameterized types (e.g. List). These replace the previous (very partial) collections from nice.lang. Functionals on collections (foreach, map, has, ...) are applicable to java.util Collections. import java.util.*; is not necessary, it is always made implicit (like for java.lang).

Testing and comments are welcome. The new (beta) version is available, as usual, at

Example code:

package test;

void main(String[] args)
  java.util.List<String> frenchNumbers = new ArrayList();
  frenchNumbers.foreach(String s => println(s));

  // Collections can be used on primitive types too (unlike Generic Java).
  java.util.List<int> numbers = new ArrayList();
  numbers.foreach(int i => println("Number " + i + " is written " + frenchNumbers[i] + " in french."));
One concern I have with java.util Collections is the UnsupportedOperationException?. It seems that the interface hierarchy was not well designed. Anybody interested to propose a fixed hierarchy?

-- DanielBonniot - 09 Sep 2002

Here a page discussing this problem:

see also FlagInterfaces for an experimental approach to solve this problem -- ArjanB

Are the methods in the StdLib? a complete set of additions to the collections api or do we need more?

And I think we need at least some sort of javadocs for the stdlib soon.

A few names of the methods could be could changed to fit better the java parts of the api. has->contains, keep->retain and "find" shouldn't throw an exception. -- ArjanB

Topic StandardLibrary . { Edit | Attach | Ref-By | Printable | Diffs | r1.17 | > | r1.16 | > | r1.15 | More }
Revision r1.3 - 04 Jun 2003 - 18:00 GMT - ArjanB
Parents: NiceDiscussions?
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.