Javadoc has some rules but not many when it comes to the compiler.

I also like RPG and enhancements are always welcome.

Having information in the object which lets you do some kind of reflection is nice but that has (almost) nothing to do with documentation.

But I think we agree that we need RPGDOCS/ILEDOCS integrated in the editor (RDi or whatever).

-----Ursprüngliche Nachricht-----
Von: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] Im Auftrag von i5
Gesendet: Mittwoch, 27. Mai 2009 19:20
An: Websphere Development Studio Client for iSeries
Betreff: Re: [WDSCI-L] Application Diagram View ---SuggestionforRPGto havesomething like JAVADOCforsubproceduresandsubroutines andmodules etc

Hi Mihael,

even Javadoc has RULES (a lot to be honest) and relies on the java compiler to do its job.

Anyway, talking about real world, I find usefull having Wizards to expose programs or service programs as Web services. They use the stored *PCML informations in the *PGM or *SRVPGM OBJECTS, now they can only render the name of the parameter and so you are lucky if the programmer used long names otherwise you get some nice CUSCD, JONBR or ITMCLS...

I don't know the meaning of "flickenteppich" but actually I like RPG and having some enhancements in RDI /WDSC would be very nice.

Marco

-------------------------
Original Message:
From: "Schmidt, Mihael" <Mihael.Schmidt@xxxxxxxxxxx>
To: Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
Cc:
Date: Wednesday, May 27 2009 04:09 PM
Subject: Re: [WDSCI-L] Application Diagram View --- SuggestionforRPGto havesomething like JAVADOC forsubproceduresandsubroutines andmodules etc
standard docs/tags: no problem with that as long as it provides the basic idea of iledocs. if it would provide as much as javadocs, it would be ok for me.

naming convention: for what?
standard location: do you mean inside the code? that definitly must defined but there are not many options.

attached to the compiled object: i don't think that is needed or even wanted. why do you want to have the docs with the object instead of nicely wrapped into html/pdf/whatever. for working with tools it is more needed with the source than the compiled object, especially if there is no direct connection between source and compiled object. means: what good does it do you to know the documentation of a procedure if you don't know which prototype copybook you need to include in your pgm. that would only be good if you don't have the source at all. IMO that doesn't work out nicely in the real world/is not needed in the real world.

you can do everything yourself except the RDi integration part. that is something rational must do. and my guess is they won't do it. IBM hasn't done it for over a decade and they won't do it now.

i'm currently in the general mood of "roll your own" and IBM sucks when it comes to features for RPG.

why did we get a xml-sax opcode when there was a fine port of expat out there. on the other hand where is the xml-dom opcode? RPG is becoming a "flickenteppich" as we would say in germany. they are just patching it (the language) instead of having a real concept IMO.

just my 2 cents.

Mihael

-----Ursprüngliche Nachricht-----
Von: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] Im Auftrag von i5
Gesendet: Montag, 25. Mai 2009 15:10
An: Websphere Development Studio Client for iSeries
Betreff: Re: [WDSCI-L] Application Diagram View --- SuggestionforRPGto havesomething like JAVADOC forsubproceduresandsubroutines andmodules etc

Hi Mihael, please read my "too much" as the result of some reflections:

"some docs for programs and procedures attached to the prototypes"

docs - any "standard" format?
attached - How, using a naming convention?
attached - Where, again using a standard location?

Probably the easiest way (not for me anyway) is developing a plug-in. Please note "Probably".

Instead my basic idea about "if we hover over the program/procedure in code and if we use code completion" is having something standard and SELF-CONTAINED provided in the prototype. The compiler problem, maybe, is making the comment available in other places rather than only in RDI/WDSC. (i.e PGMINFO(*PCML : *MODULE)) .

Marco

-------------------------
Original Message:
From: "Schmidt, Mihael" <Mihael.Schmidt@xxxxxxxxxxx>
To: Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
Cc:
Date: Monday, May 25 2009 05:58 AM
Subject: Re: [WDSCI-L] Application Diagram View --- Suggestion forRPGto havesomething like JAVADOC for subproceduresandsubroutines andmodules etc
Hey, just think about what was written:

I'm asking just for the tools (RDi) to parse the documentation and display it on hover and you are asking for a change in the compiler (because I think that would mean a new keyword) AND a change in the tools (RDi) to display the info.

So now what is too much?!

Mihael

-----Ursprüngliche Nachricht-----
Von: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] Im Auftrag von i5
Gesendet: Samstag, 23. Mai 2009 11:17
An: Websphere Development Studio Client for iSeries
Betreff: Re: [WDSCI-L] Application Diagram View --- Suggestion forRPGto havesomething like JAVADOC for subproceduresandsubroutines andmodules etc

-------------------------
Original Message:
From: "Schmidt, Mihael" <Mihael.Schmidt@xxxxxxxxxxx>

Though it would be nice to have some docs for programs and procedures attached to the prototypes and have it on-the-fly in RDi and hopefully without having to manually refresh the outline every time which really sucks. So we can have the docs of the program/procedure if we hover over the program/procedure in code and if we use code completion.
-------------------------

Docs maybe is too much, even a simple keyword COMMENT('Some help text') will be GREAT.

Just a dreamer .

Marco


-----
Sent with DeskNow Lite - Free mail & groupware server http://www.desknow.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.