Re: [ooc-compiler] Proposal for an Email-Module; RFC

[Michael v. A. <mi...@de...>]

Marco Oetken <Mar...@we...> writes:

> Hello!
> 
> I would like to have your comments on my idea
> implementing the module described below. 
> I want to use libadt. Does anyone think that
> the String-Module is not sufficient for holding
> single lines of the mailheader and the body?

For the "simple" case (moderately sized messages, not MIME formatted,
etc.) any string represention will do.  This includes a string for
every line, the whole mail in a single string, or storing the mail in
an instance of IO:Memory (part of libxml, a in-memory channel
implementation).

Btw, Stewart and I are mulling splitting the current ADT:String into
ADT:String (immutable) and ADT:StringBuffer (mutable) -- see my
attached answer to Stewart.  Does anyone like to comment on this?

-- mva


From: Michael van Acken <mi...@de...>
Subject: Re: Language framework
To: Stewart Greenhill <sgr...@ip...>
Date: 15 May 2001 11:19:56 +0200

Stewart Greenhill <sgr...@ip...> writes:

> How about this: merge Language:StringBuffer with the buffer-like bits of
> ADT:String (Insert, Delete, Replace) into a new ADT:StringBuffer. Replace
> the old ADT:String with the functionality in Language:String plus any
> functionality in ADT:String that does not change the value of the string
> (Equals, HashCode, Copy, Extract). That's what I thought you were
> proposing.

While I have in mind to add an immutable string data type to the
language eventually, I don't think this will happen in the near
future.  Adding immutable strings as a library is an option, but I
believe this is a also a rather huge leap in Oberon philosophy (see
below).

> This would clearly separate mutable and immutable strings. I think
> its important that the primary utility string type is immutable, so
> that reference to strings can be safely shared. Unfortunately, this
> would break any existing clients of ADT:String but there may not be
> too many of these yet.

The Oberon view on "strings" is quite fuzzy IMO.  We have the concept
of string constants, for which only the compiler has a type of its
own, and some built-in operators and the `Strings' module.  In a way,
the operators and `Strings' _define_ the Oberon concept of strings.
The key "ideas" presented there are: a) memory managment is done by
the user ("if you use `Strings', make sure you have allocated enough
space"), and b) mutability (changes work within the pre-allocated
space).

The current ADT:String addresses the memory managment issue by
managing a heap object on its own, but explicitly permits changes to
the string object.  Because the low-level character data is also
exposed (ADT:String.array is an exported read-only pointer), there is
no way the compiler can enforce that the array is not modified.
Please note that I want to keep the "array" field exported even with
this loophole, because I'm using it quite often to analyse character
data or to write out the string's data.

I'm using ADT:String quite often (a quick count reveals 60+ imports),
but this is no reason to change it -- provided only the module and
type name must be replaced.