Feature/pseudo source #1788
Feature/pseudo source #1788
Conversation
|
The feature is cool but it raises a few concerns of mine.
I'm just trying to figure out the actual use case behind it 😉 |
|
At first I did not get this concept - what was "pseudo source"? Then I found this comment on the idea issue #1387, which explains the concept of pseudo source and the use case for it. I definitely think the concept needs a very thorough description in the documentation, since the term and purpose and use is not obvious. If I'm having trouble understanding this, other users may as well. This concept is not for me... I don't have a use case for it and use other build methods. Mainly the BUILD command from Scott Klement, which I modified to allow me to use a sub-directory from the full path as the object library. This tool has suited me well through the years. 😃 I don't know if the majority of our users has the need for this feature - I guess most already have their build procedures in place for object types other than programs, like me, and won't switch to use pseudo sources. I was skeptical about the idea of pseudo sources on issue #1387, and I still am. Sorry about that, but I want to be honest. But for those having a need for pseudo sources, this is a great enhancement, for sure. 👍 Again, sorry for being so grumpy - and even close to the weekend! 😆 |
|
I have asked the original feature requester to leave his feedback to your comments here. |
|
I was the original requestor for this enhancement, and it helps to understand my background is a large organization (LUG member) that has used Aldon / Lmi / RDO i for many years, as that is what our shop uses. I'm also interested in Git, modernization, and Devops, and Ci/Cd, and bringing these concepts to the i. I have been using VS Code and Liam's extension since it was a thing, and RDi for years before that. These days I still go to RDi for some things, but prefer VS Code for most things. Why use pseudo source? LMi /Aldon has managed non source objects for many years, both without source, and with pseudo source. Over the years our shop decided to start using pseudo source for all non source objects that we manage through Aldon. You have greater observability, and a better understanding of the objects on your system if you do this. A specific instance I can recall as an on call developer was spending hours in the middle of the night when the system went down due to a dtaq that had reached its limit. Not having the pseudosource for the dtaq object meant i had to go to a third party tool (taatool) to see how the object was defined (what is the max size attribute, did it reclaim records, etc). I also had to 'check out' an ID with elevated authority to even do that. When you manage non-source objects with pseudo source, you not only have a quick reference to the current object definition, but you also have a historical record of the object, assuming you use some kind of source control. |
|
Why have pseudo source as a built in action? Why not just use the extension's cl command function that is already built in? There are several answers to this.
|
I can think of at least 3 build tools that already handle pseudo source. Rocket Aldon, Arcad, and Bob. I'm sure the other big ones do too, though I don't have any first hand knowledge. You do make a good point that they probably don't handle it the same. |
|
Thank you for the detailed description of the background for your request for pseudo source in Code for IBM i. I had already guessed that the request came from a LUG member, so I'm not surprised. I understand why you like pseudo source for objects that is not compiled from source. It helps in documentation and version control, as you describe. I also understand your desire for having an action to make it more convenient to "build" objects like programs etc. However, this extension is used by all kind of users - users from LUG members and users in small shops with only one or few developers. The extension is a great and free alternative to the commercial, bigger products like Merlin and RDi, which often are out of reach of the developers in the small shops. So the extension should work optimally for the majority of the users, and special functions geared toward a minority of users should be avoided if possible - especially if the function introduces new elements in the UI, that all users are exposed to, using the function or not. Since VS Code is made up of extensions, it is my opinion that the pseudo source function should be implemented in its own extension - using Code for IBM i as the API for the IBM i. Then the (few?) users needing this functionality could install the pseudo code extension on top of Code for IBM i, and the (many?) users not interested in this feature could continue with Code for IBM i as it is. I will go through your arguments:
Understandable. You build source objects using an action - and you could create your own action for building non-source objects (maybe using Bob?) in Code for IBM i today. There is no need for a default action for this.
Actions are very convenient and easy to access. However, default actions are shown to every user - not just the ones requiring the action. Remember, what's convenient for you may be inconvenient for other users.
Agree - but the UI for users not using pseudo source are affected by the pseudo source feature. An action never used by them will take up space and may require additional keystrokes or mouse movement to move over.
Agreed - but it still should be optional and not forced to all users of this extension. I'm for opt-in and not opt-out. Thank you for taking the time to describe the reasons for your request and arguments for why this should be included in Code for IBM i. I'm not opposing the functionality, just that it should be forced into Code for IBM i. I hope you understand my reasoning... |
Funnily enough, this was my original idea. For sure it more likely belongs in another extension (as does the ability to execute single CL lines that exists today, e.g. #1387), but does it belong in the CL extension? Or another unique extension? |
|
@worksofliam A new extension - all users have the CL extension and inserting the feature here would be the same as in this extension... |
|
Okay, so my plan is to move both the CL runner and pseudo runner into a new extension. I'll do that next week! |
|
Thanks for sharing your thoughts @JDubbTX ! It sparkled a good discussion and it looks we're headed in the right direction 😄 |
|
I'm fine with the opt-in, and not making it a default - but disagree it should be in its own extension. I'm not crazy about extensions that are not stand alone, and require other extensions to work. How would this work without code for IBM i? What is the reasoning for making it its own extension instead of just adding a setting to turn it on? Even if it could be stand alone, what is the use case for having it while not having code4i? |
I also think what was lost in my request in ryver was the ability to run DDL as pseudo source as well. It is common to have a list of SQL commands that define DDL objects, like tables, indexes, triggers, etc. Admitedly I don't know if code 4 i already has this capability. Even if it did, I would want to be able to create those objects the same way - as a built in action that I can turn on, instead of having to define my own. |
|
Links to other extensions are already in play today for Code for IBM i: it requires other extensions and some extensions require Code for IBM i:
RDi has the same pluggable architecture - think of the great iSphere plugin, which adds functionality to RDi like TODO's, labels, compare across systems etc. on top of the functionality already in RDi. Actually, all IDE I can think of has this pluggable architecture... and relations between extensions / plugins are not an issue in my experience. VS Code is great at handling related extensions. I've only had plugin problems in RDi, where I had to install iSphere manually because the upgrade function did not work. Another reason for having code in a separate extension is to keep the Code for IBM i code base to a minimum - making it easier to enhance, test and maintain the code. If all code and functions related to IBM i were in Code for IBM i, development would have slowed tremendously and the extension would not have been at the level it is today. I don't think you will experience any problems if pseudo source becomes a separate extension. As said, VS Code will handle it for you.
Having SQL DDL commands to define SQL objects like tables, indexes, view, procedures, functions, sequences etc. stored in a source member / streamfile and having build procedures for these objects is common practice in most IBM i shops that I know of. The build procedures can be initiated by an action in Code for IBM i - like the build for programs and other non-SQL objects. The action would issue the RUNSQLSTM CL command, which can execute SQL scripts in members and streamfiles. If you want to run a single SQL statements in a group of SQL DDL statements, you can install the DB2 for IBM i extension, which allows you to do that. IMHO it's best to keep the build procedure outside C4i and not turn C4i into a "build machine", since there are many different build methods (CL program, SQL script, Bob, make file etc) and people / companies use the one(s) suited for them. Default actions for each and every one of the build methods would clutter the UI and annoy the users - but actions can be added and modified by the users to fit their IBM i installation, thus precisely configured to each users needs. I hope and expect you will have a great experience, even with pseudo source as a separate extension and not a native feature of Code for IBM i. 😃 |
I understand where you are coming from. I really do. I feel like this line of thinking can be taken too far though. I think we both agree that basic functionality should be included with the base extension. Imagine if every little function of code 4 i were in its own extension? That would gum up the marketplace and cause great confusion. I would also say that just because it has been done, isn't necessarily an argument for what should be done - provide the specific reasoning that those extensions are not part of the base code4i, and apply the same reasoning to what we are talking about here. Putting code into separate extensions isn't the same as writing good, modularized code.
I'm familiar with iSphere and use it a bunch. Some of its functionality, especially the member text decorations, I wonder why is wasn't included in base RDi. (It is included by default in code4i). The good folks that maintain RDi really should include that, its pretty basic.
I'm not arguing against having a plugin architecture. I love the extensibility of VSCode and I use it in many capacities, not just IBM i development. My argument is that it doesn't make sense to put this specific function in a plugin / extension and that it deserves to be part of the main code4i extension, with an additional notion that it doesn't provide enough functionality to warrant its own extension.
Respectfully, I feel like you are overestimating the amount of code bloat and UI obtrusiveness that the functionality will bring, especially if you make it opt in, which I've already conceded. That being said, I'm not a javascript or typescript guru - having just some exposure in the last couple of years, so if this adds a thousand lines of code, by all means keep it seperate. My hunch is that Liam can get this done in a few paragraphs, but again, perhaps I'm wrong.
I agree I won't have problems. I mainly work in development containers these days, and when I build my development container for IBM i one of the first things I do is install the IBM i development pack. This would be part of the development pack, correct? I would think it would certainly disserve to be, over some less disserving extensions that are already part of it. Do you use the development pack, or do you prefer to install extensions individually? If you do use the development pack, you would have to turn around and uninstall the extension each time you installed the development pack, so by putting it in its own extension, you are actually adding steps to the majority of folks who won't use it.
Doesn't this make my point, not yours? If its common practice in IBM i shops to have build procedures, why not support a build action for these by default? I'm really not trying to be difficult, I just want to take a moment and clarify what we are discussing. It sounds like you are agreeing with me that having pseudo source is both a good thing, and "common practice". The main points of contention I see are 1) should this pseudo source functionality be enabled by default (I've already conceded that it doesn't need to be)? and 2) Should it be in its own extension?
I disagree with this wholeheartedly. If not for building, then code 4 i would just be for browsing and looking at code. You can do that without code4i, and even browse syntax highlighted RPG and CL code without code4i. I'm not advocating for a full fledged build solution like Bob, Arcad, and the like. To me, building pseudo source is just simple, and no different than building source objects, and encourages good development practice. If you don't like having the extra functionality, just don't turn it on. Since we have agreed to make it opt in, most folks probably won't even realize its there.
I have enjoyed this discourse, and I DO have a "great experience". You maintainers of Code4i are absolute superstars in my book. I appreciate the addition of my suggestion in whatever form it ends up taking. |
Changes
Adds a new default Action called 'Run as pseudo source', which runs the individual CL commands from the source code and prints info the existing diagnostic instance to show the results.
Only applies to sources where the extension matches the list as defined in the new user settings.
Checklist
console.logs I added