Re: Java compatibility issues (WAS: MF having issues?)

Oliver Wong wrote:

Oliver,

COBOL Collections - so far as COBOL is concerned it's a little
complicated. Firstly Fujitsu, Hitachi and Micro Focus independently
produced their own collection 'styles', while J4 had a dummy-run (in
'96) going from memory, which was put on ice until Bill Klein
resurrected the topic - I know fully well his buddies on J4 at the time,
*absolutely* loved him for doing that.

So there is a TR for Collections, again don't know where they are at, as
I know longer look. However going from memory :-

OrderedCollection
KeyedCollection ( which I identify as Dictionary)
SortedCollection
IteratorClass (known to me in M/F as Callback )
Collection Exceptions

Now the current M/F Collection Hierarchy is, and I wont attempt to
indent, because that is just plain tedious :-

Collection
Bag
sequencedcollection
ArrayedCollection
Array
ByteArray
CharacterArray
UnicodeString
EventArray
dynamicArrayedCollection
orderedcollection
sortedcollection
ValueSet
dictionary
identitydictionary
SymbolTable
IdentitySet
DBCScharacterarray
entryCallback
Callback
ThreadedCallback

The above is based on Smalltalk. Starting at Collection the shown
hierarchy inherits from Dependent which inherits from Base. Above is not
totally exhaustive as M/F also has Association which is used to build
Dictionaries, plus classes covering COBOL PICX and COMP5 etc.

Your familiarity with what is available in Java, no doubt is immediately
raising a question as to the disparity between the above two. I tried to
tell 'em. One more nail in the coffin - what's currently available in
F/J and M/F, and what is intended means there will never be any
portability between PC-compilers, nor a snow's chance in hell of
swapping code.

As an example my usage is SortedCollection (80% plus), sometimes
OrderedCollection and Dictionary. Possibly the most frequently used is
CharacterArray used to turn text into displayable objects and vice
versa, for GUI-ing. But whichever of the 'common' classes I use, they
are constantly zipping backwards and forwards to many of the others for
support.

Now to quickly answer some of the observations you made :-

> The way it works is when you create a new ArrayList, you can specify its
> initial capacity. If you don't, it just uses some arbitrary
> non-documented value (e.g. perhaps 10). If the size of the collection is
> the same as it's capacity, and you try to add another item, the
> collection will silently grow itself and, now having sufficient
> capacity, accept your item, all under the cover without you being aware
> that anything peculiar has happened.
>
> There's an "ensureCapacity" method which you provide an integer
> representing the desired capacity. When you call this, the ArrayList
> will grow if the requested capacity is larger than the actual one, or
> simply ignore your message if the actual capacity is already larger than
> the requested one. There's no direct way of finding out what the actual
> capacity is (you could find out by using a debugger, for example).
>
> There's also a "trimToSize" method which takes no arguments or
> parameters at all. The intended usage is for when you've finished
> changing the size of the collection (i.e. not adding or removing items
> anymore), you can then instruct the ArrayList to size itself so that its
> capacity exactly matches its current size to save a bit of memory.

Slightly different wording to yours, but that's what I can get. Your
comment about a default size of 10 - same thing with M/F
>
>    Not sure if I understood the question, but if you want a dictionary
> and you want to associate a key with two objects (and always exactly two
> objects for every single key), you could create a so-called "Pair"
> class, pack both your objects into the pair, then put the pair into the
> dictionary.

Can't have a duplicate Key in a collection anymore than you can have a
duplicate key in a COBOL file. Try to add an element creating a
duplicate key - it just gets ignored. I can have :

Key---> then Data
-----------------
12345 Micro Focus Ltd
12347 Micro Focus Ltd

but I can't have :

Micro Focus Ltd	12345
Micro Focus Ltd 12347

Wasn't too clear about your reference to Pairs - but the following
example from Adele Goldberg (Smalltalk 80) is allowable to find
'Opposites' from the Key :-

Key---> then Data
-----------------
hot	cold
push	pull
stop	go
come	go
front	back
top	bottom

I think 'Pairs' you are possibly referring to something slightly different ?

>    I don't know if the library you're using supports this, but droplists
> in Java can have an "ListCellRenderer" object associated with them. The
> ListCellRenderer object takes the actual content of the list, and takes
> care of their appearances on the GUI.

That was fun - ran the demo you recommended. Basically its a dropdown
plus an area for a bitmap - n'est-il pas ? Haven't got into webbing but
M/F does have features for URL-ing, so design the dialog to take the
piggy, cat, or dog bitmap - in theory should work. But I'm only likely
to take a crack at it in Java.

Lots of good support in GUI classes but not totally. Gets tough say
colouring a dropdown - you need from memory WmDrawItem, so that for each
element, you draw the text area then colour it. Associated with that I
require properties OwnerDraw and HasStrings - the only way I can get the
latter is to visually check-off those two properties when using the
visual Dialog Editor. For dynamic use there just aren't methods for
"OwnerDraw" and "HasStrings" !

Thanks for the interesting info - Java gets more and more appealing
unless somebody really plugs C. I haven't heard back  from the two
COBOLers I know are switching to C#. My suspicion 'We'll go with C# 'cos
we think we are safer with Bill Gates.  Now as to what trick might be
pulled in Winders if we go Java....?"  Just a guess, but that might be
their logic.

Jimmy