Future reuse of code

[Marco van de Voort]

Re: Future reuse of code

In article <20030815133308 .2c81e74f.spamt rap@flash-gordon.me.uk>, Mark Gordon wrote:[color=blue]
> Marco van de Voort <marcov@stack.n l> wrote:[/color]
[color=blue]
> Definitely.
>[color=green][color=darkred]
>> > Platform independent code happens naturally with almost no effort in
>> > Java. It is requires considerable effort in C++. You can't
>> > convince me otherwise because I have done both.[/color]
>>
>> Me too for the opposite :-)[/color]
>
> I've not done C++,[/color]

Only a bit. (pretty much the amount needed for Delphi compability. Basic
classes and such)
[color=blue]
> but I have done Pascal (had to use non-portable
> features)[/color]

Like?

[Stephane Richard]

Re: Future reuse of code

Let's see now.

in Java's history:

Java 1 and Java 2 are very different languages that try to look the same.

Between Java 2 1.3 and Java 2 1.4 there are discrepencies that can make code
execute differently or not work at all. As far as portable, what is
portable in it's definition?

"code that can be compile with little to no alterations to the code on
different plateforms. I think people are confusing portable and
multiplatform. Sure Java is Multiplatform. why? because Java runs
compiled on a lot of platforms. But at what cost? As long asn the java
creators keep on thinking with the same frame of thoughts as they are right
now, Java will:

1. Never be portable as they think that providing the whole platform with
their language is the only way to do things. Take the code to that
platform, the JVM, there is no way, by any definition of portable, that the
code to the jvm is portable or multiplatform. but the results of this code
are multi platform. or the same JVM would compile as is on anything you try
to compile on. Hence there's different JVM's to install on different
platforms. Think of it, JVM is, "dare I say", an OS inside the OS you run it
in. How can that be optimal and as fast as any other technic and
technology?

2. Never be as fast as most other languages...sti ll today JVM and the JDK
lack in speed because there's so much things to do/consider/create different
as per the machine/platform it's running on.

3. The problem here isn't the language itself. Java's idea of a programming
language is pretty good, everything being an object makes for perhaps a
little bit clearer code, but then again, not on all aspects. The problem is
the way the language is implemented. The way you need the JVM (which runs
on top of your OS) to run java code where you need nothing but the OS on any
other languages to me those are the major flaws if the whole Java idium.
But the language IS fun to use. Maybe Java should be it's own OS instead of
a virtual machine running on top of any existing OS then it would cut that
"interface/intermediate" layer and end up faster, by design.

Again people, don't confuse portable code, and multiplatform applications
these are very distinct fields althought they both exist for the same cause
:-).

So as per the definition of portable, C is definitaly the strong winning.
As multiplatform Jave is better (as in simpler, but not necessarily better
in general than C (speed wise, resource wise and the likes) But C, with a
little bit more work (upfront as in at the beginning of the development
process) is many times faster and smaller.

--
Stéphane Richard
Senior Software and Technology Supervisor

http://www.totalweb-inc.com

For all your hosting and related needs
"Howard Brazee" <howard@brazee. net> wrote in message
news:bhiost$k4n $1@peabody.colo rado.edu...[color=blue]
>
> On 15-Aug-2003, ruse@webmail.co .za (goose) wrote:
>[color=green]
> > like I originally said "java has its advantages, but portability isn't
> > one of them".[/color]
>
> Yep. That's what you said. I haven't seen any evidence on this thread[/color]
that[color=blue]
> you have convinced anybody that this is true.[/color]

[Howard Brazee]

Re: Future reuse of code


On 15-Aug-2003, "Stephane Richard" <stephane.richa rd@verizon.net> wrote:
[color=blue]
> 3. The problem here isn't the language itself. Java's idea of a programming
> language is pretty good, everything being an object makes for perhaps a
> little bit clearer code, but then again, not on all aspects. The problem is
> the way the language is implemented. The way you need the JVM (which runs
> on top of your OS) to run java code where you need nothing but the OS on any
> other languages to me those are the major flaws if the whole Java idium.
> But the language IS fun to use. Maybe Java should be it's own OS instead of
> a virtual machine running on top of any existing OS then it would cut that
> "interface/intermediate" layer and end up faster, by design.[/color]

Everything choice involves costs and benefits. This "problem" is also Java's
biggest strength.

[Scott Moore]

Re: Future reuse of code

Please stop crossposting this material to the Pascal groups. It has no
bearing on
the subject matter there.

Thank you.

[WB]

Re: Future reuse of code

Kevin Easton wrote:
[color=blue]
> In comp.lang.c WB <su-news@bossi.com> wrote:
>[color=green]
>>Roedy Green wrote:
>>[color=darkred]
>>>Don't be silly. Look at any C code designed to run on many platforms.
>>>It is riddled with macros to pull off the feat.
>>>
>>>You can do a few simple things like parse the command line, open a
>>>flat file in a platform independent way, but not even the size of int
>>>is guaranteed unless you play some games with macros.[/color]
>>
>>Well, no you can't open a file in a generic way. Opening a file on a PC
>>is different than opening a file on a mainframe. You need a special
>>library to do this:
>>
>>#ifdef I370
>> #include <lcio.h>
>>#endif
>>
>>Which works with the SAS C compiler.
>>
>>Plus, all your variables and function names need to be 8 characters or
>>less, AND mixed case is ignored, so VarA and VARA are the same, thanks
>>to the mainframe linker.
>>
>>At least it was a few years ago. Things may have chnaged since then....[/color]
>
>
> If it doesn't support fopen, then it's not a hosted C implementation.[/color]

Who said anything about fopen? You still use fopen, but MUST have the
additional include file, which adds support for the mainframe way of
doing things.
[color=blue]
>
> If it doesn't handle identifiers case-sensitively, then it's not a
> conforming C implementation at all.[/color]

The mainframe C compiler is quite happy with long var names and mixed
case. It is the linker which falls over. Actually is only "sees" up to 8
characters, but does not complain at all. This leads to very interesting
behaviour :-((

Oh yes, I also forgot about tri-graphs:
[ becomes ??(
] becomes ??)
^ becomes ??\
~ becomes ??-


I ended up writing a converter which takes the original C code, and
converts it to something that will run on the mainframe. Yuck.

[Richard Plinston]

Re: Future reuse of code

Tor Iver Wilhelmsen wrote:
[color=blue]
> GCC the compiler is pointless without libraries,[/color]

No, that is not true. On Unix things like open() read() are _system_ calls
not library routines. It is possible to write an application in C without
any libraries at all. In fact most of the libraries are written in C and
thus only require to be coded in the program to give that functionality.
[color=blue]
> and libraries in C/C++ differ between platforms.[/color]

Well of course the standard libraries are _implemented_ differently, but
they provide the same programmer interface and act as a layer between the C
program and the 'platform' specifics.

For gcc the libraries give the same implementation on all platforms they
are implemented on - in fact gcc and its libraries probably run on naerly
every platform that full Java does, and a couple that don't have a full
Java, such as MS-DOS/EMX.

One could also argue that the Java VM 'differes between platform' in that
the VM for one environment won't work on another. In that case the Java VM
is acting in the same way as the C libraries.
[color=blue]
> Java's libraries let you write complex applications without a million
> #ifdef _LINUX_ or whatever.[/color]

Your not very widely read on this are you: - never let facts get in the way
of a good prejudice ?

It may be true that _most_ implementations of Sun's JVM at the same version
will run the same program unchanged, it may not be true that, say, a JVM
1.2 will run all Java 1.4 programs or that a servlet will run as an applet.
There are also dozens of JVMs out there which have subtle differences which
may need to be coded around: MS J+, Kaffe, Latte, JanosVM, Alta, even
Blackdown.

These provide specialised environments or enhancements or are for platforms
not catered for by Sun.

All that you are saying is that if one only works within a very limited set
of Java, say the standard VM from Sun of a given version then all programs
will run unchanged.

One could do that for C/C++ too. One never needs an #ifdef if one only
uses those wnvironments that never need an #ifdef.

In any case many of the JVMs are written mostly in C.

[Donald Tees]

Re: Future reuse of code

"Roedy Green" <roedy@mindprod .com> wrote in message
news:3vdojvs3as c4icm23agl41sfu hct80dpf7@4ax.c om...[color=blue]
> On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
> >It is impossible to
> >write incorrect Java code?[/color]
>
> The difference in, that equivalent program in Java would either work
> or not work. It would give the same results on all platforms. With
> the C version, you don't know if it works on other platforms until you
> test it.
>[/color]

This is getting silly. You do not know if *any* program in *any* language
on *any* computer works until you test it.

Donald

[Alex]

Re: Future reuse of code

In comp.lang.c Roedy Green <roedy@mindprod .com> wrote:[color=blue]
> On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :[/color]
[color=blue][color=green]
>>It is impossible to
>>write incorrect Java code?[/color][/color]
[color=blue]
> The difference in, that equivalent program in Java would either work
> or not work. It would give the same results on all platforms. With
> the C version, you don't know if it works on other platforms until you
> test it.[/color]

Subject to the run-time environment being thoroughly tested to work
the same on all the potential platforms. Not unlike a conforming C
compiler, wouldn't you say?

The bottom line is, you cannot expect 1-to-1 conformance between
implementations . You should, therefore, always test your programs
on all target platforms. This applies to Java just as much as it
does to C.

Alex

[Mark McIntyre]

Re: Future reuse of code

On Fri, 15 Aug 2003 00:59:41 GMT, in comp.lang.c , Roedy Green
<roedy@mindprod .com> wrote:
[color=blue]
>On Thu, 14 Aug 2003 23:02:16 GMT, Kevin Easton
><kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
>>People who *think* they need an exact-width type, rather than an
>>at-least width type, are usually wrong.[/color]
>
>But then people write code thinking of only their own platform where
>int is say 32 bits, and hand it to someone else whose int is 16 bits.
>It does not work.[/color]

well yes, but thats hardly surprising, since they're bad programmers.
[color=blue]
> It requires foresight[/color]

no, it requires an understanding of the limits of the size of an int.
[color=blue]
>and a macro to make that
>code work on both platforms. It is thus foolish to claim C or C++
>works naturally multiplatform. It requires extra effort.[/color]

it requires knowledge.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:49:11 GMT, in comp.lang.c , Roedy Green
<roedy@mindprod .com> wrote:
[color=blue]
>On Fri, 15 Aug 2003 01:43:18 GMT, Kevin Easton
><kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
>>Is it possible to write non-portable code in C? Yes.
>>
>>Does it follow from this that it is impossible to write portable code in
>>C? No.[/color]
>
>Straw man argument Kevin.
>
>You made the silly assertion that ALL C code would run unmodified on
>any platform correctly. That is nonsense.[/color]

If you insert the word conforming, its correct.
"All conforming C code will run on any conforming platform correctly".

I need hardly point out thatr *precisely* the same is true of Java,
C++ or for that matter DCL. If you rely on nonstandard features of
your specific implementation, such as the size of an int, or some
class thats not part of the standard, then you're screwed.
[color=blue]
>I merely stated that writing cross platform code in C or C++ takes
>considerable effort.[/color]

This remark is flat out wrong.

I've written hundreds of thousands of lines of C and a few tens of Ks
of C++, all of which was completely portable between VMS, Solaris and
NT, and it required NO special effort, merely sticking to the language
spec. The only time I had a problem was when faced with a pre-ansi
compiler on the Sun box.
[color=blue]
>You need to find third party
>libraries supported on all your platforms.[/color]

Only if you want to do things not part of the standard implementation.
Just as, in fact, you would need to do with Java, if you wanted, say,
to access vacuum tubes or drive a stepping motor.
[color=blue]
>You need to generate separate executables.[/color]

You do with Java too - each implementation has a separate executable
called the Java Runtime.
[color=blue]
> You need to test separately, and you need a ton of compile time
>macros to make the magic work.[/color]

Bollocks. Utter and total bollocks. Stop trolling.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark Gordon]

Re: Future reuse of code

On Fri, 15 Aug 2003 20:28:48 GMT
WB <su-news@bossi.com> wrote:
[color=blue]
> Kevin Easton wrote:
>[color=green]
> > In comp.lang.c WB <su-news@bossi.com> wrote:
> >[color=darkred]
> >>Roedy Green wrote:
> >>
> >>>Don't be silly. Look at any C code designed to run on many
> >>>platforms. It is riddled with macros to pull off the feat.
> >>>
> >>>You can do a few simple things like parse the command line, open a
> >>>flat file in a platform independent way, but not even the size of
> >>>int is guaranteed unless you play some games with macros.
> >>
> >>Well, no you can't open a file in a generic way. Opening a file on a
> >>PC is different than opening a file on a mainframe. You need a
> >>special library to do this:
> >>
> >>#ifdef I370
> >> #include <lcio.h>
> >>#endif
> >>
> >>Which works with the SAS C compiler.
> >>
> >>Plus, all your variables and function names need to be 8 characters
> >>or less, AND mixed case is ignored, so VarA and VARA are the same,
> >>thanks to the mainframe linker.
> >>
> >>At least it was a few years ago. Things may have chnaged since
> >>then....[/color]
> >
> >
> > If it doesn't support fopen, then it's not a hosted C
> > implementation.[/color]
>
> Who said anything about fopen? You still use fopen, but MUST have the
> additional include file, which adds support for the mainframe way of
> doing things.[/color]

In which case it is *not* a conforming hosted C implementation. To be
conforming the inclusion of stdio.h to provide a definition of the FILE
type is entirely sufficient. Of course, you might need to use something
else to deal with directories etc.
[color=blue][color=green]
> > If it doesn't handle identifiers case-sensitively, then it's not a
> > conforming C implementation at all.[/color]
>
> The mainframe C compiler is quite happy with long var names and mixed
> case. It is the linker which falls over. Actually is only "sees" up to
> 8 characters, but does not complain at all. This leads to very
> interesting behaviour :-(([/color]

From memory I think the 8 character limit is legal but I'm not sure
about the case sensitivity. I always avoid having names only
distinguished by case, so it has never been an issue for me.
[color=blue]
> Oh yes, I also forgot about tri-graphs:
> [ becomes ??(
> ] becomes ??)
> ^ becomes ??\
> ~ becomes ??-[/color]

Trigraphs are the other way around. You put "??(" in the source and it
is replaced by "[".
[color=blue]
> I ended up writing a converter which takes the original C code, and
> converts it to something that will run on the mainframe. Yuck.[/color]

Sounds like the mainframe did not have a conforming C implementation to
me.
--
Mark Gordon

[Mark Gordon]

Re: Future reuse of code

On Fri, 15 Aug 2003 14:27:31 +0000 (UTC)
Marco van de Voort <marcov@stack.n l> wrote:
[color=blue]
> In article <20030815133308 .2c81e74f.spamt rap@flash-gordon.me.uk>, Mark
> Gordon wrote:[color=green]
> > Marco van de Voort <marcov@stack.n l> wrote:[/color]
>[color=green]
> > Definitely.
> >[color=darkred]
> >> > Platform independent code happens naturally with almost no effort[/color]
> >in> > Java. It is requires considerable effort in C++. You can't[color=darkred]
> >> > convince me otherwise because I have done both.
> >>
> >> Me too for the opposite :-)[/color]
> >
> > I've not done C++,[/color]
>
> Only a bit. (pretty much the amount needed for Delphi compability.
> Basic classes and such)
>[color=green]
> > but I have done Pascal (had to use non-portable
> > features)[/color]
>
> Like?[/color]

Trapping the "STOP" key on an HP workstation. Only used this on the HP.

Separately compiled files (has that been added to the standard?) Handled
differently on the different Pascal implementations I used.

A non-standard way to access third party libraries. Handled differently
on the different Pascal implementations I used.

Probably a number of other things that I can't remember now.

I think the Delphi diverged even further, although I helped people with
Delphi rather than using it myself.
--
Mark Gordon

[Richard Heathfield]

Re: Future reuse of code

[Please observe followup to comp.lang.c; thanks.]

Mark McIntyre wrote:
[color=blue]
> Its impossible to write a "strictly compforming" programme.[/color]

int main(void)
{
return 0;
}

--
Richard Heathfield : binary@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

Re: Future reuse of code

[Please observe followups to comp.lang.c; thanks.]

Mark McIntyre wrote:

<snip>[color=blue][color=green]
>>[/color]
> "All conforming C code will run on any conforming platform correctly".[/color]

Counter-example:

void main(void)
{
}

This program is conforming (even though it invokes undefined behaviour),
because at least one conforming implementation accepts it. On the other
hand, it's not difficult to find at least one conforming implementation
that rejects it.

--
Richard Heathfield : binary@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[James J. Gavan]

4Re: Future reuse of code

Apologies in advance guys, but this is a long winded one - to do with the
application of OO COBOL, but some of it certainly applies to the other
languages.
YOU'VE BEEN WARNED - SO QUIT HERE IF NOT INTERESTED !:-
--------------------------------------------------------------------------------

"Peter E.C. Dashwood" wrote:
[color=blue]
> "James J. Gavan" <jjgavan@shaw.c a> wrote in message
> news:3F3B1F7F.B 0095A32@shaw.ca ...
>
> Jimmy,
>
> your post raised a few questions.
>
> Perhaps you could elucidate...?
>
> How can a queue (FIFO) and a stack (LIFO) be implemented with an ORDERED or
> SORTED Collection?
>
> By definition, these collections have to be UNORDERED or UNSORTED.
>
> I certainly hope J4 are not going to overturn the accepted concepts of queue
> and stack in order to implement these collection types. But then, nothing
> they did would surprise me...
>[/color]

Trying to trip me up with superior knowledge <G>. Mentioning Sorted Collections
was definitely a slip of the pen ! They would be a non sequitur - either
elements are added according to the default Sort or you sub-class to get your
own customized sort !

However Ordered Collections - Yes. Recall I once suggested Sequential
Collections - but you didn't like that definition. To clarify from my on-line
help :-
--------------------------------------------
Orderedcollecti on
An OrderedCollecti on manages the storage of elements in the order in which they
were added to the collection. One of the main advantages of OrderedCollecti ons
over Arrays is that they can grow dynamically as more elements are added. You
can use OrderedCollecti ons to implement stacks and queues.
----------------------------------------------------------

Probably the most common use being to read in data and the latest record is
added as the last element (the COBOL file sequential approach). However, there
is nothing to stop you inserting at an index position of your choice - when you
are aware of 'positioning'. The sequential approach implies "add" (at the
bottom) with no reference to an index. Naturally with callbacks you can iterate
against all the elements in the collection, plus when a condition fails you can
get out of the callback with "quitIteration" .

My example was an attempt to show retrieval in its simplest form by index.
Supporting the Ordered Collection is the PRIVATE class Sequenced Collection. Be
assured there are methods to achieve the points you made, remove one (element)
or block (of elements), replace one or block etc., even "reverse" the order of
the collection. You may not be thrilled with J4, but they aren't a bunch of
dummies - and I'm sure they will cover all points. As to FIFO/LIFO - difficult
to see that I would have a use unless I ever got into Simulation.
[color=blue][color=green]
> > If you haven't got what you want - James Gosling's fault. (He was born
> > in Calgary).
> > Guess he should have checked the Smalltalk hierarchy more closely before
> > he sat down to re-invent the wheel <G>.
> >[/color]
> Is he "REALLY using OO COBOL"...?[/color]

And you so often accuse me of mis-reading you ! How the hell did you arrive at
the above crummy statement. The two volume tome 'Core Java' is quite candid that
Java had an initial set of lists - subsequently they had to back-track and add
on features which had been missed. Not my words, but 'Core Java' published by
Sun !
[color=blue]
>
> Using the free or cheapest tools you can get to do a job is quite distinct
> from using the best tools available to do the job.
>
> If you can't afford to use the "right" tools for the job I don't see any
> dishonesty in saying so.
>
> Eiter way, it doesn't alter the fact that using the right tools for the job
> (rather than making whatever tools you have fit the job) is a preferred
> strategy.
>[/color]

Agreed. when originally writing I was thinking of including the words 'best
tool', but let them slip by. However that is a very subjective thing, 'best'.
For the most part I would suggest that most language users in this thread would
*prefer* to facilitate features in their 'parent' language - the one they are
most comfortable with. If all else fails, then they look at other languages,
particularly if they can find a pre canned routine/function. And it is not a
question of making 'your tools fit the job'. That is ridiculous - first call
does your language handle it, (may require a bit of research for methods
available), if not, then go the 'outside' route.
[color=blue]
> As you don't quote the OCX site, we can't judge for ourselves whether the
> suggested component was appropriate or not.[/color]

Without back-tracking to look up the site - be assured it DOES have rich
features, (but from the marketing blurbs, possibly some overloading - see
below). BUT without getting into OCX the point was it was easily achievable in
COBOL - and I might add, by RE-USING a large chunk of classes which I had
already written.
[color=blue]
>
> Trapping a Windows or keyboard event is feasible in any language that deals
> with GUI development. What makes COBOL (even OO COBOL) MORE "right" for this
> than VB, C, C++, or Java?[/color]

Again your misinterpretati on of what I wrote. If your preference is COBOL then
COBOL is MORE 'right' if it lets you do something easily. If your 'parent' is VB
why would you go looking at C/Java for the solution - if it is easily attainable
in VB ?
[color=blue]
>
> People who used the recommended OCX component wouldn't care what language
> they embedded it in, and they have the same re-use advantages that you
> realised by doing it in COBOL.
>
> The point here is that components transcend languages.
>
> (That is one reason why I personally consider them a better solution...)[/color]

As stated above, I think the general tendency will probably be language of
preference. (Don't really see too many of them invoking COBOL - do you ?). If
however, and to quote your phrase, "It's only programming', and you believe
something is more viable in another language, then go for a potpourri - the
latter approach implying you carry around more baggage with your application
because you are now adding libraries for both languages.

I suggested baggage, accompanying components could be a problem - you summarily
dismissed that as irrelevant. It can come to haunt you.. Recall Jerry's problem
with that very large file - and the attendant problem of getting extracts over
to user sites. He concluded he would drop the project and take up pig farming;
as an alternative he suggested another solution - along with the data give each
user site a free disk <G>. Difficult we know with an existing and functioning
database - but the true answer goes back to design - that file design should
probably be seriously revamped. Baggage or volumes are not something that can
be dismissed lightly. The frugality on storage when this game started some 40-45
years ago, is just as valid today, providing it doesn't impede performance.
[color=blue]
>
> This is a total non sequitur. What has my support of components got to do
> with anything you posted? The implication seems to be that by opting for a
> component based approach, I am not "REALLY" using OO COBOL.
>
> That is unfair and uncalled for.
>
> I don't really mind whether you think I do so or not, and it is just one of
> the tools I use, but I have been using it long enough that I was able to
> post an analysis and explanation of it to an ASP based Web site, at a time
> when you were assuring the COBOL community that "nobody understands OO
> COBOL".[/color]

A deliberate misquote on your part. Certainly I had initial difficulties getting
a handle on OO and a certain gentleman PECD is on record as saying the same
thing ! I am now a reasonably happy camper - but in view of a quote below
coming from you - ????????
[color=blue]
>
> (Here's the link, in case you've forgotten...:
> http://www.aspalliance.com/aldotnet/...boldotnet.aspx)
> The same link also contains the advice regarding "best tools for the job"
> which you were so dismissive of above...)[/color]

This is the first time I read it, but I do recall a COBOLer jumping into clc and
asking about this MS .NET example. He was somewhat pissed off when I declined,
along the lines from any neighbour you might have up the road, "Hey you program
all day long. Why can't you tell me why my disk doesn't work or my screen
doesn't come on ? To describe it with some detail, I think, required knowledge
of the interplay between MS and Fujitsu NET COBOL - I was not prepared to trip
over my feet !

Not our Pete, this was a challenge not to be refused. Sorry but your quotes in
RED are not much more helpful than a Dick and Jane classic ! Spot didn't even
get a look in. To be absolutely blunt - why did you even bother ?

Let's educate the masses here who may not be familiar with COBOL :-

COBOL has four Divisions :-
-------------------------------------
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
------------------------------------
OK guys get cracking and start coding in COBOL. You want more ? You want jam on
it ?.
[color=blue]
>
> Now your understanding has advanced to the point where you know how to
> handle some Windows events in it...
>
> Keep going...eventua lly you may learn how to build components with it...
>
> If that happens, maybe we can talk.[/color]

Typically snotty wind up from you - although this time you haven't attempted to
wrap your venom with a "<G>", which of course is a caveat which translates to "
Hey ! I was only kidding", if the recipient feels offended.. (That comment on
your style was initially observed by somebody else, not me !).

Maybe we can talk ? Not likely - unless you are considerably more forthcoming in
the future. While I accept that Components ARE viable, (in certain areas), - I
don't buy into your approach. Forgive me, but it appears that you've arrived at
a set of conclusions, have cast your thoughts in concrete and then made the
problems fit the solution.. In a recent message Robert used the phrase "Your
approach was myopic". I'm afraid I agree. I said a while back he is no dummy,
but his diplomatic skills definitely need a brush-up <G> Any criticism of your
perceived and 'correct' approach results in a snarl - as in your recent snotty
reply to Donald about components.

I'll mention it seeing as you've plugged your 38 years in IT. As of this June
I've been 40 years in the game, starting in my beloved Zummerzett (Somerset). I
still prefer to call it EDP. The first 12 years spent in design - that's the
stage before wee programmers started doing chicken scratches on coding pads.
Without question you can probably lose me in programming techniques - but don't
even try when it comes to design, bearing in mind I was using random access from
day one. Get the design wrong and you are on a hiding to nothing, no matter how
much clever coding you put into it..

I've certainly been bewildered over the years by your view of OO COBOL.
Clarification has only recently surfaced. Let's take some points in progression
:

1. You used an early version of Fujitsu OO COBOL which DIDN'T include
collections. You could get those coupled with a fast Sort package for about
another $1,000 (?). Surprise, surprise. I wonder how many didn't buy that
extension - so they programmed ignoring collections(lis ts). I assume at the time
you fitted into that category. Since then collections may be a part of later
versions of F/J OO - but I've never seen you make reference to them.

You may have your viewpoint - but it's my firm belief that lists/collections are
an inherently important feature in the OO family, and working without them is
like having one arm held behind your back. Lists have always been a part of
design, even using procedural COBOL - I recall mention of Robert designing
chained lists. Similarly, I think Michael did the same with his good ole
favourite - BASIC.

2. Some 5 or 7 of us started chatting privately about OO COBOL. Out of the blue
you came on like the converted. You had discovered Java, but found the language
'underwhelming' . You evangelized how good Java was and started distributing Java
articles to us. Huh ? Not just me, others must have felt the same - 'We are here
to discuss OO COBOL, what has Java got to do with it ?".

3. Then the Java mode went silent. Quietly you had back-tracked to Fujitsu to do
your components - sure I know you will dispute that, but the first indications
you ever gave were that you were using Fujitsu, plus the follow-up, that Fujitsu
generates your intermediate code, so you really don't have to worry too much
about OO.

4. In the C.L.C News Group I have from time to time posted sample code, on one
occasion explaining for Warren about instantiation. This particular message was
followed up by a snide remark from you about the irrelevance. "What gives ?", I
thought, "Where's his hang up ?".

5. Then I made the mistake of saying that before you even start coding you first
have to design your class hiearchies.(I bet you missed it - Roedy Green (Java)
made the same point in one of his first messages in this thread). Back you came
- No! You don't have to do it that way. "Huh ?", I'm saying again to myself.

6. Within clc we got into some friendly discussion on Components and you
attempted to spell out your String2Num - but it was never specific code and your
quotes were, "You could do it this way or this way.....". I countered by
suggesting that using a generic dialog, and creating instances of it I could
achieve the same for a series of dialogs. I posted the code specific to an
entryfield. Your response, "It may work for you, but it appears to contain too
much maintenance". I could arrive at two conclusions from that, (1) You didn't
have a bloody clue what I was describing, or (2) Having settled on Components as
your religion of choice - no deviations allowed, no prisoners taken ! My guess -
# 2,with a slight element of #1 - because you probably didn't even read it !
Note I am NOT claiming to have found the answer, just an alternative approach,
which at the moment works - as I've said before - down the road I might fall
flat on my face. In your case that couldn't possibly happen could it ?

7. I'm sorry but your mindset is often illustrated in two of your pet phrases,
"I am not convinced....." , or "I am not persuaded....". See - I do read what you
write, and although I don't go in for copious cross-reference of messages, I do
have a bloody good memory. I'll be SOL if Alzheimer's ever kicks in !

8.. Having run through the above, which conveys my bewilderment as to your
thinking, for me we now arrive at the real kicker :-
[color=blue]
> 8th August
>"OO for me is only important insofar as it provides the key to component
>building.[/color]
[color=blue]
>There are too many disadvantages in pure OO...lack of cross platform
>Classes, difficulty in calling one set of classes from a language based on a[/color]
different Foundation, and so on. Simply by wrapping the objects as[color=blue][color=green]
>>components, all these disadvantages disappear and they can be dropped[/color]
>anywhere. My fervour is for components, not OO, although I also believe that
>OO is a superior model for programming than procedural.".[/color]

The first sentence implies OO is a non-starter - it doesn't fit your thinking.

Your list of disadvantages - "lack of cross platform classes" - I assume here
you are referring to portability - the tug-o-war our C and Java friends are not
winning (or as Howard said, 'Neither are they convincing anybody'). Certainly of
great significance if you are MARKETING components. But check those component
sites - so many modules have been written to address specific languages -
excluding COBOL ! Get into a master and servant relationship, the boss legally
owns the components you design and you aren't going to sell them anywhere - not
unless the boss wants to market them.

"Difficulty in calling one set of classes from a language based on a
different Foundation". Not in my book. I can happily invoke Java from my COBOL
compiler, coupled with COBOL classes written to specifically invoke Java. Same
goes for C with specific data types to handle inter language operability - a
point stressed in the Standard COBOL 2002. (Don't go asking for samples - I
don't use either feature. Disbelieve me if you wish - or go take a peep at
microfocus.com home page and see entries for Java, plus examples).

Note carefully, I am not rejecting components, but the argument that they are
the panacea or cure-all for the future of IT. And in the process your
conclusions have led you to dismiss major OO features. We now have OO-COBOL and
a sub-product called Dashwood-OO COBOL - just leave out the bits you think don't
matter.

You referred us to the following article :-

http://www.aboutlegacycoding.com/

I thought I'd check, as I didn't recall it had any source code. Correction it
does :-
------------------------------------------
Environment Division.
…
Repository.
Class OLE AS "*OLE".
…
Working-Storage Section.
01 S2Nobj-Name pic x(128) value "STRING2NUM.Str ing2Num.1".
01 S2Nobj OBJECT REFERENCE OLE.
…
Procedure Division.
…
invoke OLE "CREATE-OBJECT"
using S2Nobj-Name
returning S2Nojb.

Now I can get the component to display its Properties by:

Invoke S2Nobj "ShowStuff" using strInput

Cf. the JavaScript above.

S2N.ShowStuff(s trInput)

It isn't SO different, is it? (And you thought this OO stuff was hard <G>)
-------------------------------------------------------------------------------

Again something you probably missed from Roedy - he also commented that OO
developers needed to attain a skill set.

I didn't write the following - I think I got it from clc :-
-------------------------------------------------------------------------------
$set ooctrl(+P)
class-control.
word is class "$OLE$word.appl ication".
working-storage section.
01 theWord object reference.
procedure division.
invoke word "new" returning theWord
invoke theWord "setVisible " using by value 1
invoke theWord "Quit"
invoke theWord "finalize" returning theWord
stop run.
-------------------------------------------------------

We *know* they both work, because you are going to tell me the first one
definitely works. And I'm going to tell you the second works because I compiled
and ran it.
BUT - to describe a concept - they are both as useful as teats on a bull !

Yours was an enjoyable article - But the above - ZOWEE ! That really gives me a
lot of information if I want to get into Components. Sorry, but I'm the Doubting
Thomas from the Twelve. Until I can see and touch the source - I ain't buying. I
want to see a concept liberally supported by source before I make my *own*
judgement, before I go down a different path. (If I want to follow through on
Components, what better than the Aussie academic, Brian Henderson-Sellers -
oodles of articles and diagrams, plus I can buy an armful of books from him, (he
is the author of course), on Component generalizations - but no source !).

Now here's the real problem I have with Components, because although you have
supplied the weapon you haven't illustrated the ammunition.

Let's talk something basic like dates. Please produce me a component. Well
certainly in COBOL we are already well armed with at least some eight Date
intrinsic functions which can be CALLED in traditional fashion from a COBOL
program. I don't use them all, but if I did would put them in a super class
"Dates" as individual methods. Coupled with those, there are generalized
methods, (mainly PRIVATE), required for date validation, format checking etc.
(Real bread and butter stuff).

Then we move on - return of validity checks and formatting output to return to
the invoker. Do you want ccyy/mm/dd, mm/dd/ccyy, dd/mm/ccyy, and all the other
possible permutations, or spelled out with names of months and days of week,
(both full and abbreviated). Throw in you also want spacing or hyphens or
obliques. So I live in Canada - better give me English and French. I live in the
US better give me those two plus Spanish and Portuguese. I don't need to expand
- go into the possibilities in Europe. Somewhere down the road our Asian friends
get into the act.
Do I really want a component that does all the above, even providing me with
Hindi and Urdu !

It doesn't require much visualizing to realize that this component is a MONSTER.
In response to queries from Howard Brazlee, you were adamant you don't maintain
components; you write a new one. Really ? How quickly do we arrive at Date
Component Version 1005 ?

The only sensible solution is the one that Roedy alluded to - we have to design
classes and in this case a whole hierarchy just for Dates, super doing the true
polymorphic functions, and sub-classed to handle formatting and spoken
languages .
It is conceivable that such a hierarchy may well embrace something like 200 or
more classes, (albeit some of them may be tables (arrays - for you other folks)
of literals - possibly spanning only a page of source). That still leaves us at
the monster level. But, with the right tools, sub-classes can be pulled to
create selective DLLs - and for the version I want I can be assured that it is
not carrying the baggage associated with Hindi and Urdu, or perhaps, the Slavic
group of languages.

None of the above occurs as a result of starting to code, although proto-typing
can begin. The first step is the overall hierachial design.

Would you seriously attempt to cover the whole gambit above in one of your
component structures ? Possibly you could, but to achieve it you need
sub-classing - and I'm not getting the message that is what you are doing. I
have no intention of going into detail here to spell it out, but it is clearly
obvious to me, and many others into "true" OO, all the above can be achieved via
hierarchies and sub-classing - so where does a Component have the edge ?

Without clear concise code as to the route you would take - how can I even guess
what your approach would be to the above problem - which is an absolute natural
for conventional use of OO with classes, sub-classes, plus throw in $10 words
like polymorphism and encapsulation..

I have been extremely blunt. I feel very angry at what I perceive to be
deception - possibly not your intent. Plus I am really alarmed that you are
sending the younger folks off ecstatically into space, and are they truly aware
of what the implicatins are with your 'shortcut' approach to OO ? The anger is
in the same vein as I'm bloody angry with George Dubya and his clan over the
mythical WMDs - seeing as I was one of the two Canucks who thought the U.S.
should go in - but would have preferred if Daddy Bush had done it 10 years ago.

I've stayed out of clc - largely because of your ramblings - and your dismissal
of the conventional concept of OO really pissed me off. I do not intend to go
into a tit for tat, trying to score points with a clever wordsmith. (I would
caution you however, Oscar Wilde was a clever wordsmith - and he finished up in
jail !).

If you make some valid counter-argument then I may respond - otherwsie silence.

In all my ramblings above I do NOT make claim to being an expert in OO. Mentally
I'm still back there in the UK with the big red letter "L" attached to my car -
"Learner - beware". Being down in the Antipodes I'm hardly likely to knock you
over anyway. However, if I did it in the UK and you told the judge "I was
walking along the pavement and he knocked me down", the judge would award you a
handsome sum of crisp pound notes. You'd be SOL in N. America - "Your honour, I
was walking along the pavement and he knocked me down". Judge responds, "Case
dismissed. You should have been walking on the sidewalk, not the pavement !".

As the cartoons used to say, 'THAT'S ALL FOLKS !".

Jimmy, Calgary AB