Re: [ooc-compiler] libadt questions

[Stewart G. <gre...@mu...>]

Marco Oetken wrote:

> I wanted to implement a small program and I needed a few
> helpful objects, which I expected to be similar to those in
> libadt. I am using VisualOberon for my program which makes
> it at this point impossible to directly use libadt.
> But I looked at the documentation to see how I implement
> Riders for the VOListModel e.g. I recognized that it is not
> supported to have multiple manipulating Riders in libadt
> and I am wondering what reason it has and if there was too
> little use for such an implementation.

I haven't looked at libadt recently, but from memory the development of
the library was suspended (or shelved?) because the language lacked
support for some of the sorts of things that we wanted to do (eg.
interfaces).

The Java Collection framework supports multiple riders (ie. Iterators)
for collections. The standard Iterator interface has a facility to
remove the last object returned by the iterator. However, this is an
optional method and I suspect that it may or may not be implemented
depending on whether the iteration state can be easily maintained during
deletion. For simple structures like linked lists it might not
difficult. While the actual interfaces don't explain this, some of the
exceptions hint at what's happening here:

<QUOTE>
public class ConcurrentModificationException
extends RuntimeException

This exception may be thrown by methods that have detected concurrent
modification of a backing object when such modification is not
permissible. 

For example, it is not permssible for one thread to modify a Collection
while another thread is iterating over it. In general, the results of
the iteration are undefined under these circumstances. Some Iterator
implementations (including those of all the collection implementations
provided by the SDK) may choose to throw this exception if this behavior
is detected. Iterators that do this are known as fail-fast iterators, as
they fail quickly and cleanly, rather that risking arbitrary,
non-deterministic behavior at an undetermined time in the future. 
</QUOTE>

I implemented (in Component Pascal) a file-based B+ tree with riders.
The problem here is that addition and deletion may cause the keys to be
redistibuted amongst pages as the tree is balanced. This completely
invalidates any internal state stored in another rider that may be
accessing the same B+ tree (detected by checking the <valid> field in
the Rider prior to doing an operation). I'm not saying that it can't be
done, but in some data structures it might be difficult to preserve the
Rider state under changes to the structure.
 
> The next thing I would like to have is an object that simplifies
> reading files in a format which contains a lot unused information.
> Has someone thought about some kind of filter which can be
> used by a program like a Reader? I have been using an extra
> program run by Rts.System to convert a file into a new format and
> after that I am reading the converted file. But I thought it
> would be faster and nicer to convert that file on the fly.
> What do the others in this list do?

Maybe you could implement a filter as a Channel. I think someone wrote a
Channel filter for doing decompression on the fly, but I can't remember
the details.

Cheers,
  Stewart