|
midrange.com
Disclaimer: these are not comments to the substance of this thread - just
technical nit-picking...
> I think that just as the C++ class/member approach to programming is
> superior to the flat ile module approach, the class/member organization
and
> access to system api's will prove superior to the standalone system api.
"C++ class/member approach" cannot be superior or inferior to ILE, simply
because they are apples and oranges.
ILE does not preclude "C++ class/member approach" in any way - in fact C++
is happily implemented in ILE without any problems whatsoever...
> If an os uses the class/mbr approach the os is organizationally forced
> to provide all the dtaara api's as class mbr functions, accessible from
any language.
With all respect, how os can enforce access to "class mbr functions" in
*any" language, if this *any* language happens not to support "class mbr"
paradigm - e.g. C does not have any notion of "class mbr function" ... ?
Alexei Pytel
"Steve
Richter" To: <MI400@midrange.com>
<srichter@Auto cc:
Coder.com> Subject: Re: mi access to a dtaara
Sent by:
owner-mi400@mi
drange.com
06/01/2001
04:11 PM
Please respond
to MI400
>
>You will note that MS does not provide access to absolutely everything
>within the OS. There is a selected set of objects that are accessible by
>the .NET approach. Unless and until MS provides access to absolutely
every
>object in the OS, your analogy is not valid.
>
>This is innovative?!?! Isn't this accomplished by simply providing header
>files for the objects they choose to make "manageable" or "public" or
>whatever? Is this somehow different from the IBM API approach? What's
new
>here?
>--
>Dennis Lovelady Fayetteville, GA
Dennis,
I dont have working knowledge of .NET. Just 2 yrs of c++ and the win32 api.
So I will defer to you on what it really offers.
Imo it is relevant to an as400 api discussion bc it provides the working
example of another approach.
I think that just as the C++ class/member approach to programming is
superior to the flat ile module approach, the class/member organization and
access to system api's will prove superior to the standalone system api.
An example. This dtaara api issue. The as400 does provide api's for all
dtaara functions. Some like ChgDtaAra and DltDtaAra have to be called from
a
cl pgm, others like the rtvdtaara api can be called from a hll pgm. If an
os
uses the class/mbr approach the os is organizationally forced to provide
all
the dtaara api's as class mbr functions, accessible from any language.
2nd example. Chgs and additions to the api. As400 adds addn parms to its
api, adds another rtn fmt name ( objd0100, objd0200, ... ) when it adds a
new feature to its api. This makes the api increasing more complex to use.
Some parms are ignored, others must be set to a specific value, ... In
the
class/mbr paradigm, when an api gets a new feature, a new mbr function is
added to the class. No chg to the original mbr function. The os knows which
one is being called based on the nbr of arguments passed, the types of
these
arguments.
See mark, no mention of .Net <g>
Have a nice weekend,
Steve Richter
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
