RE: Re[2]: New Opcodes - %SETCELL

I would agree with this as well.  Some may think the numbers are higher, but
that's because we interact with 1% of that 10% on this list and elsewhere.  

Here's why.  BIFs are built in (by definition even...heheh..).  If one could
write BIFs and have them build in, meaning not having to bind objects, etc,
you could use them more.  But, since we're not Java or C programmers used to
using #includes, a lot don't understand what it's about.

I have been putting a few of the modules I have written that have been
helpful on Netshare400.com's website (Http://www.netshare400.com) under the
source samples section.  I hope to add more and if anyone else has any
samples (RPGIV please...) I'd be happy to put them up there.

Bradley V. Stone
BVS/Tools
http://www.bvstools.com



> -----Original Message-----
> From: John P Carr [mailto:jpcarr@tredegar.com]
> Sent: Tuesday, September 07, 1999 9:32 AM
> To: RPG400-L
> Subject: Re: Re[2]: New Opcodes - %SETCELL
> 
> 
> 
>       >The only real problem
>       >I have with APIs is the documentation. There must be a special
> college
>       >course that you take so that you can write impossible 
> to understand
> text.
>       >At least the documentation for BIFs is understandable.
> 
>       So what you're saying is even if 90% of the programmers 
> use BIF's
>       less than (say) 10%  will understand/use  API's ?   
>       (Of the programming public at large not as represented 
> by this list)
> 
>       I would agree with that.   If Toronto has time to do 
> other things,
> I 
>       think that Native support for IFS affinity should be a priority.
> 
>       IMHO
>       John Carr
> 
>       Joe Teff
> 
> 
>       From:   Joe Teff@jteff19 on 09/07/99 09:20 AM
>       To:     RPG400-L@RPG400-L@midrange.com@SMTP@EXCHCONNECT
>       cc:      
> 
>       Subject:        Re: Re[2]: New Opcodes - %SETCELL
> 
>       >     Strikes me as the sort of thing that belongs in a library
> function
>       >     (which could be implemented as a service program):
>       >
>       >       eval  mycell = GetCell("/test.xls":"r1c1")
>       >
>       >     IMHO, a BIF should reflect a need that a *large* 
> proportion of
> RPG
>       >     programmers will have.  BIFs for every conceivabe esoteric
> application
>       >     don't seem workable to me.
> 
>       This is a "catch-22". If updating spreadsheets were 
> easier then it
> would
>       be a common occurrence and if it was a common 
> occurrence then the
>       process to do it would become easier. I really don't 
> have a problem
> with
>       an API in a service program rather than a BIF. In fact, 
> the first
> thing I do
>       when I encounter an API I need to use, is to create an external
> procedure
>       (in a service program) only passing the parms that are 
> neccessary.
> Once
>       that is done, I can then use my procedure like a BIF. 
> The only real
> problem
>       I have with APIs is the documentation. There must be a special
> college
>       course that you take so that you can write impossible 
> to understand
> text.
>       At least the documentation for BIFs is understandable.
> 
>       Joe Teff
> 
> 
>       +---
>       | This is the RPG/400 Mailing List!
>       | To submit a new message, send your mail to 
> RPG400-L@midrange.com.
>       | To subscribe to this list send email to 
> RPG400-L-SUB@midrange.com.
>       | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
>       | Questions should be directed to the list owner/operator:
> david@midrange.com
>       +---
> 
> 
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---