[ooc-compiler] Re: libadt issues (was: Re: Possible improvements)

[Marco O. <Mar...@In...>]

>Von: Michael van Acken <mi...@de...>
>An: Vis...@ed...
>Cc: ooc...@li...
>Betreff: libadt issues (was: Re: Possible improvements)
>Datum: Don, 17. Aug 2000 9:32 Uhr
>

> [I'm CCing this to the ooc-compiler list as well.]
>
> Tim Teulings <ti...@ed...> writes:
>
>> [...] But in fact I would prefer a libadt solution - if libadt would
>> be that feature rich and stable :-/ Perhaps one should add libadt to
>> the compiler and mark it as "to be changed", so that people realize
>> that it does exist, use it and improve it? Michael, what is your
>> opinion?
>
> The libadt attempt ran into a dead end because we were too ambitiuous
> in our goals.  Oberon-2 does not have the language features to built a
> class hierarchy with different implementations of a single logical
> concept.  For example, defining "what is a list?" and writing several
> interchangeable implementations, and then integrating them into huge
> unifying class hierarchy which adds concepts above and below "list"
> does not work.
>
> That being said, replacing the modules with standalone versions that
> serve one particular need very well, and extending them when new needs
> are found, will probably work out better.  In fact, this is the
> approach I took when I needed some functionality in the ooc2 sources,
> that was already present in the libadt.  So I used Object (renaming
> the module from AcObject to ADT:Object) and Storage (renamed to
> ADT:Object:Storage, removing support for "Alien", which should be
> implemented in a separate "StorageAlien" module).  This gave me
> persistent data.  Later I added a simple but _very_ useful Dictionary
> module, implementing a hash from an object (rather, an object address)
> to another object, and an ArrayList module, which resembles the Java
> ArrayList class to some extend.  To emphasize the point: Instead of
> trying to do a grand unifying class hierarchy, I simply added modules
> that fit one particular need, and I expect them to change or extend if
> new needs arise.
>
> The same pragmatic approach could be used for libadt.  If one
> discovers a need for a particular abstract data type, I would like to
> see a short discussion on the mailing list to gather some additional
> ideas, insights, and suggestions, then an implementation that is
>
>   a) is preferably already used in some existing code,
>   b) documented,
>   c) has possibly some automated testing code,
>   d) and is finally discussed a little bit more.
>
> You will notice that I dropped any "specification and discussion of
> the specification" stage.  Being used in existing code and being
> documented is IMO a better replacement for this, and it leads to
> tangible results instead of prose.  The last step (d) may or may not
> lead to changes.  I _always_ expect the modules and even their
> interface to change.  They will never be set in stone.  If there is
> room for improvement, and someone actually implements an improvement,
> then this will be fine.  Regardless of the changes to code or
> interface.
>
>
> Ok, this was a rather long digression.  Now I'll try to get to the
> question ;-) Adding libadt to the compiler distribution is something
> that I would consider.  There are some "but"s attached, though.
> First, I would not add it in the current form.  At least some module
> renaming is necessary.  Any modules that aren't used by anyone are
> dropped.  Features that aren't considered useful and that are not used
> are dropped (possibly to be included again later in another and more
> suitable form).  Documentation must be complete before a module is
> added.  The documentation must be in the format used by, e.g., the
> libxml and ooc2 sources (Remember the HTML documentation prototype I
> showed around 2 weeks ago?  This is based on the embedded
> Texinfo-style documentation.  The documentation processor has been
> getting better since.)  Finally, non-trivial modules need some
> automated tests in some form.
>
> Please consider that adding libadt to the compiler distribution may
> not be as helpful as you think.  The oo2c distrib is very stable.  It
> takes months to accumulate enough changes to warrant a new release.
> _If_ libadt is ever used, it will change more frequently than the
> compiler distrib.  There must be separate distribution, and libadt
> will never be part of the official core library.  This is no reason
> not to include it, of course, provided that there is enough support
> and someone is willing to maintain the separate distribution file.
>
> The very short summary of this very long posting is this: If libadt is
> used, I am willing to add it to the compiler distribution.  "Being
> used" is the most important requirement.  The other requirements have
> a lower priority.
>
> -- mva
>
>                    *** Mailinglist ¥VisualOberon¥ ***
>

------------------
I am using libadt in some programs. The doublelinked lists and the strings.
I guess both are very useful an could be used in VisualOberon and elsewhere.
I have extended String and built a module, which implements Filenames
(not portable though -- just for unix-like naming conventions).
Michael states "being used" is very important. I regularly avoid using
String because they are not supported in the standard library modules
of OOC. It would be nice to have String supported by Readers e.g.

ListDL and String seem to be most useful libadt modules and I suggest
to include them into OOC. I could provide my filenamesmodule, too.
Those 2 (3) modules will be used!

Greetings,
 Marco