Idea Delivered

This will be available with the XPP 9.4 version release.

xyPerl: fix lookup for shared perl functions (modules), should be 1. current job, 2. style library, 3.syslib, 4. xpp perl folder

The lookup for CSS imported modules (the @import things) is the normal style lookup sequence 1. current job, 2. style library, 3.syslib.
And that allows you to 'share' common CSS settings among similar style bundles in a nice and convenient way.
(which is by the way a big plus when working with CSS compared to working with IF stylesheets).

It would be nice to have xyPerl work in the same way.
In similar styles you probably want to share 'perl functions' in the same way as you do with CSS settings.
Or even have perl functions (e.g. frills processing loops) that can be used by any of the styles you have.
(and yes this could be done by putting your perl module in the xpp perl folder, but that folder is not accessible from the pathfinder interface, so not a convenient place)

'Sharing' common things in a perl environment is done through using perl modules.
Modules are called in into the main xyPer program using a 'use' statement.
Perl will lookup a module based on the paths in the @INC array.
It would be nice if XPP could add the current job, the style library and the Lsyslib to the @INC for us.

Currently we can more or less do this ourselves but we need to hard code the style library name in the main xyPerl as inside composition we do not know what is the style library for a particular job.

Things would work a lot better if XPP can manipulate the @INC for us.

REMARK:
it would also be nice if there would be a possibility to force XPP to reload the perl modules you use in your main xyPerl.
Currently you need to store/exit and reopen the division in order to make this happen.
and that is very uncool while you are developing your shared functions.

Bart Terryn
Parents

  • I am going to chime in here and say that nothing can be done.
    When we implemented the lookup for PERL we provided a "xz/perl" folder for system wide PERL files and modules that implement XPP functions. Customers discovered this folder and proceeded to add their own stuff to the folder. While we specifically did not say that the folder was free to add custom PERL, customers went ahead and put modules and other PERL files there, even though they were supposed to use the style libraries.
    When custom PERL modules were added, we needed to guarantee the XPP PERL modules were used or it would create the scenario where customer extensions could break composition; hence the search order.
    Yes they are a different search order, but just pretend that "xz/perl" does not exist for a location and use the rest of @INC as shown.
    I'm afraid that at this point, changing the search order would break customer implementations, and as I said open XPP up to false "bugs" as customers inadvertently override system level files.

Comment

  • I am going to chime in here and say that nothing can be done.
    When we implemented the lookup for PERL we provided a "xz/perl" folder for system wide PERL files and modules that implement XPP functions. Customers discovered this folder and proceeded to add their own stuff to the folder. While we specifically did not say that the folder was free to add custom PERL, customers went ahead and put modules and other PERL files there, even though they were supposed to use the style libraries.
    When custom PERL modules were added, we needed to guarantee the XPP PERL modules were used or it would create the scenario where customer extensions could break composition; hence the search order.
    Yes they are a different search order, but just pretend that "xz/perl" does not exist for a location and use the rest of @INC as shown.
    I'm afraid that at this point, changing the search order would break customer implementations, and as I said open XPP up to false "bugs" as customers inadvertently override system level files.

Children