Post by Robert on Jun 13, 2023 11:59:52 GMT -5
There is a better and easier way to do this that does not involving deriving profiles. I will leave this here for documentation purposes, but this idea should be considered withdrawn.
Disclosure: This idea is not strictly necessary, it would take some effort to implement, and is thus not a priority. In other words, I am giving you every reason to NOT do it. Primarily, I want the concept documented so that if someday it were seen as useful, you'd have this post as a starting point.
This idea amounts to an extension of EFT, and I see it as something to be done after the unification of EFT with the various Options GUI file-type lists (assuming THAT is done). The "derived" part of it will be explained shortly.
MVS and Z/OS users are familiar with the concept of 'temporary data sets'. These are basically ordinary files, which exist for the duration of a job or job step, and do not have a 'permanent' file name or data set location on a disk volume. Instead, they get a system-assigned name that consists of the job name, step name, data and time and some other stuff (if my memory serves correctly; always a risky bet these days), and are allocated wherever the system deems appropriate. The value of a temporary data set is to get some disk space quickly allocated without all the manual overhead of going in and painstakingly defining every last technical detail about a file, when all you want is to just USE it.
Now, think about SPFLite's use of profiles. As useful as they are, they are also its "Achilles heel". You can't get much of anything done in SPFLite without a profile. It's the "Mother May I" feature we have all grown to love (or, not).
To try to explain the rationale for Derived Profiles, I am going to draw on experience from using EFT, and one example in particular, regarding access to Linux files. In the "Extended File Types" HELP entry, there is an example where L: is a drive letter assigned to a Linux volume. The idea is that we want to be able to edit Linux text files that use EOL LF instead of EOL CRLF. The EFT entry in this example was,
"L:\**\*.txt" = TXT_LF
This allows us to open any text file on drive L: using a clone of the TXT profile, one that has had its EOL value changed from CRLF to LF.
But, it's possible we might need to access many OTHER kinds of files, such as BAS, CPP, etc. in addition to simple text. Just as on Windows, these other file types may have unique colorization and reserved word lists. The file types are essentially the same on both systems, EXCEPT for the EOL value. Yet currently, we are forced to have two distinct profiles, since their EOL setting differs. With TXT, BAS and CPP that would require 6 profiles - 3 for Windows and 3 of them "cloned" for use with Linux. As the number of files types grows, so does the burden of cloning profiles - resources that have to be created and maintained separately.
NOW ... let us suppose that we don't WANT to have two basically identical profiles exist for the same underlying file type, but only one - even though there is that minor difference between them. How could we do it?
Here is where a structural change to SPFLite would be required. I don't see it as an enormous change, but it's still a change, and only George can say if it were too hard to pull off.
Keeping in mind the example of MVS temporary data sets, suppose we could invent a concept of a 'temporary' profile. What would a temporary profile mean? To make this idea a little more clear, and give it a unique name that would identify that it's something NEW in SPFLite, I am going to call these things "Derived Profiles".
A Derived Profile has these traits:
1. It is COPY of a permanent profile - where a 'permanent' profile is the only kind of profile that exists at present. When a copy of a permanent profile is made to create a Derived profile, the permanent one is termed the Base Profile. These names are taken from common terminology used in object-oriented programming.
2. Because a Derived profile is temporary, it likely would exist only in memory, and would disappear after an edit session using it was closed.
3. Changes to a Derived profile are not saved. In that sense, a Derived profile is similar in behavior to a LOCKED profile. The Base profile may be either LOCKED or UNLOCKED, and that part does not change how a Derived profile is handled.
4. In a PROFILE display in an edit session, the word DERIVED would appear instead of LOCKED or UNLOCKED. A DERIVED profile gets that 'attribute' by virtue of its EFT entry. It is not possible to change the DERIVED attribute to either LOCKED or UNLOCKED, or vice-versa. Once a file is opened with a derived profile, that part of it cannot be changed. You could specify a different profile if you wished (as you can now), but that 'different' profile would not be DERIVED. You can ONLY get a derived profile through the process of a normal file-open via the EFT.
5. A Derived profile gets created when an EFT entry names the Base profile PLUS one or more profile attributes that are to be modified.
Example: Suppose I want to open a Basic program file on a Linux system, and I already have a BAS profile on Windows that uses EOL CRLF. How could we do it? With an EFT entry like this:
"L:\**\*.bas" = BAS, EOL LF
The presence of the comma, and a list of one or more profile-attribute settings, is what makes the profile "derived". This causes a temporary copy of the BAS profile to be made, and then MODIFIED with the EOL LF setting as specified. This means that in order to HAVE a derived profile, something must be DIFFERENT than the Base profile. Otherwise, why make one? If I use a BAS profile exactly as-is, I don't need to "derive" it. We wouldn't go around creating temporary Derived profiles "for the fun of it", but to define one with some meaningful difference from the Base profile.
P.S. SPFLite may, or may not, be able to detect a 'needless' derived profile. That is, if BAS has EOL CRLF, an EFT entry of
"L:\**\*.bas" = BAS, EOL CRLF
would (needlessly) create a redundant copy of the BAS profile, since that already had EOL CRLF specified. This may or may not be an important issue going forward.
6. Because a derived profile is temporary, there can be any number of them active at any given time. EACH INSTANCE OF A DERIVED PROFILE IS UNIQUE. And (yet), each of them would have the same "name" as the base profile. For instance, suppose BAS files are ordinary text, but INC files are UTF8. We could say
"L:\**\*.inc" = BAS, EOL CRLF, SOURCE UTF8
If I then open a BAS file and an INC file, there would be two active Derived profiles, both using BAS as the Base profile, but individually 'modified' in different ways. BOTH would have a profile "name" of "BAS", and would share the SAME colorization and reserved-word lists as the Base profile BAS.
Finally, if you have been following this discussion, you may have noticed that Derived Profiles sure seem to resemble the (now obsolete) PROFILE USING feature. That is true. However, the advantage of Derived Profiles is that to create one, all you need is one line of text in the EFT definition, instead of having a full (USING) Profile specification that points to a regular one.
This pretty much explains the Derived Profile concept. There is no doubt much more that could be said, but this should be enough to understand the basics of it, and to further user discuss of its relative merits (if any).
Disclosure: This idea is not strictly necessary, it would take some effort to implement, and is thus not a priority. In other words, I am giving you every reason to NOT do it. Primarily, I want the concept documented so that if someday it were seen as useful, you'd have this post as a starting point.
This idea amounts to an extension of EFT, and I see it as something to be done after the unification of EFT with the various Options GUI file-type lists (assuming THAT is done). The "derived" part of it will be explained shortly.
MVS and Z/OS users are familiar with the concept of 'temporary data sets'. These are basically ordinary files, which exist for the duration of a job or job step, and do not have a 'permanent' file name or data set location on a disk volume. Instead, they get a system-assigned name that consists of the job name, step name, data and time and some other stuff (if my memory serves correctly; always a risky bet these days), and are allocated wherever the system deems appropriate. The value of a temporary data set is to get some disk space quickly allocated without all the manual overhead of going in and painstakingly defining every last technical detail about a file, when all you want is to just USE it.
Now, think about SPFLite's use of profiles. As useful as they are, they are also its "Achilles heel". You can't get much of anything done in SPFLite without a profile. It's the "Mother May I" feature we have all grown to love (or, not).
To try to explain the rationale for Derived Profiles, I am going to draw on experience from using EFT, and one example in particular, regarding access to Linux files. In the "Extended File Types" HELP entry, there is an example where L: is a drive letter assigned to a Linux volume. The idea is that we want to be able to edit Linux text files that use EOL LF instead of EOL CRLF. The EFT entry in this example was,
"L:\**\*.txt" = TXT_LF
This allows us to open any text file on drive L: using a clone of the TXT profile, one that has had its EOL value changed from CRLF to LF.
But, it's possible we might need to access many OTHER kinds of files, such as BAS, CPP, etc. in addition to simple text. Just as on Windows, these other file types may have unique colorization and reserved word lists. The file types are essentially the same on both systems, EXCEPT for the EOL value. Yet currently, we are forced to have two distinct profiles, since their EOL setting differs. With TXT, BAS and CPP that would require 6 profiles - 3 for Windows and 3 of them "cloned" for use with Linux. As the number of files types grows, so does the burden of cloning profiles - resources that have to be created and maintained separately.
NOW ... let us suppose that we don't WANT to have two basically identical profiles exist for the same underlying file type, but only one - even though there is that minor difference between them. How could we do it?
Here is where a structural change to SPFLite would be required. I don't see it as an enormous change, but it's still a change, and only George can say if it were too hard to pull off.
Keeping in mind the example of MVS temporary data sets, suppose we could invent a concept of a 'temporary' profile. What would a temporary profile mean? To make this idea a little more clear, and give it a unique name that would identify that it's something NEW in SPFLite, I am going to call these things "Derived Profiles".
A Derived Profile has these traits:
1. It is COPY of a permanent profile - where a 'permanent' profile is the only kind of profile that exists at present. When a copy of a permanent profile is made to create a Derived profile, the permanent one is termed the Base Profile. These names are taken from common terminology used in object-oriented programming.
2. Because a Derived profile is temporary, it likely would exist only in memory, and would disappear after an edit session using it was closed.
3. Changes to a Derived profile are not saved. In that sense, a Derived profile is similar in behavior to a LOCKED profile. The Base profile may be either LOCKED or UNLOCKED, and that part does not change how a Derived profile is handled.
4. In a PROFILE display in an edit session, the word DERIVED would appear instead of LOCKED or UNLOCKED. A DERIVED profile gets that 'attribute' by virtue of its EFT entry. It is not possible to change the DERIVED attribute to either LOCKED or UNLOCKED, or vice-versa. Once a file is opened with a derived profile, that part of it cannot be changed. You could specify a different profile if you wished (as you can now), but that 'different' profile would not be DERIVED. You can ONLY get a derived profile through the process of a normal file-open via the EFT.
5. A Derived profile gets created when an EFT entry names the Base profile PLUS one or more profile attributes that are to be modified.
Example: Suppose I want to open a Basic program file on a Linux system, and I already have a BAS profile on Windows that uses EOL CRLF. How could we do it? With an EFT entry like this:
"L:\**\*.bas" = BAS, EOL LF
The presence of the comma, and a list of one or more profile-attribute settings, is what makes the profile "derived". This causes a temporary copy of the BAS profile to be made, and then MODIFIED with the EOL LF setting as specified. This means that in order to HAVE a derived profile, something must be DIFFERENT than the Base profile. Otherwise, why make one? If I use a BAS profile exactly as-is, I don't need to "derive" it. We wouldn't go around creating temporary Derived profiles "for the fun of it", but to define one with some meaningful difference from the Base profile.
P.S. SPFLite may, or may not, be able to detect a 'needless' derived profile. That is, if BAS has EOL CRLF, an EFT entry of
"L:\**\*.bas" = BAS, EOL CRLF
would (needlessly) create a redundant copy of the BAS profile, since that already had EOL CRLF specified. This may or may not be an important issue going forward.
6. Because a derived profile is temporary, there can be any number of them active at any given time. EACH INSTANCE OF A DERIVED PROFILE IS UNIQUE. And (yet), each of them would have the same "name" as the base profile. For instance, suppose BAS files are ordinary text, but INC files are UTF8. We could say
"L:\**\*.inc" = BAS, EOL CRLF, SOURCE UTF8
If I then open a BAS file and an INC file, there would be two active Derived profiles, both using BAS as the Base profile, but individually 'modified' in different ways. BOTH would have a profile "name" of "BAS", and would share the SAME colorization and reserved-word lists as the Base profile BAS.
Finally, if you have been following this discussion, you may have noticed that Derived Profiles sure seem to resemble the (now obsolete) PROFILE USING feature. That is true. However, the advantage of Derived Profiles is that to create one, all you need is one line of text in the EFT definition, instead of having a full (USING) Profile specification that points to a regular one.
This pretty much explains the Derived Profile concept. There is no doubt much more that could be said, but this should be enough to understand the basics of it, and to further user discuss of its relative merits (if any).
