Please show how that is any different from Perl itself not knowing what Modules it might be used with, what modules are installed, what they do, what their dependencies are...

A Perl module *does* know that the modules it needs are installed because it indicated a dependency on them. And it *does* know what the module it needs does.

There's no way for my aXML plugin to indicate a dependency on another plugin.

>There's no way for my aXML plugin to indicate a dependency on another plugin.

Well of the 58 currently defined plugins, only 2 have dependencies on others, and both of those refer to plugins which are part of the standard set.

Saying that I need to declare dependency on a plugin from the standard set is like saying that I need to predeclare the use of standard keywords in perl;

 use use;
 use my;
 use foreach;
 
 foreach my $var (@vars) ...
[download]

Its nonsense.

Now if someone had a rare problem which they cannot solve with the standard set, and they decide what is needed is to write a brand new plugin, that plugin can depend on any of the standard set without any problems.

If they then write another plugin which depends on their first new plugin, and they try to share the second plugin with people without first sharing the first plugin, they are a moron and they deserve to be confused.... j/k come on reality check!

Also it would not be that hard to code it up so that plugins have version numbers, and can check that a given required dependency has the right version.

 my $plugins = {

        foo => sub { our $version = '0.001';
                    ...do some tom-foo-lery...

                  },

   foo_bar => sub { 

      our $version = '0.001';

      if (defined $plugins->{'foo'})
        { 
         if ($plugins->{'foo'}->version ge '0.001')
           {

            ... do some foo-bar stuff ...
     
             my $var = $plugins->{'foo'}->("hello");


            ... do some more foo-bar stuff ...

            return "result of foo-bar";
           }
          
         return 'foo_bar error; please update foo';
        }

      return 'foo_bar error; please install foo';
     }
 
   };
[download]

I dunno why you would want to do it that way around tho when you could just as easily pass the result of foo to foo_bar at the aXML level.

  <foo_bar><foo>hello</foo></foo_bar>
[download]

Saying that I need to declare dependency on a plugin from the standard set is like saying that I need to predeclare the use of standard keywords in perl;

Exactly. Up until this point, you said we had to do this:

use my;   # Because Some::Plugin needs it.
use for;  # Because Some::Plugin needs it.
use Some::Plugin;
[download]

Like you said, it's nonsense.

But it looks like you just changed your story again!

Are you now saying that &lab; is standard and will always work out of the box?

Are you now saying that <post_include>common/lab</post_include> is standard and will always work out of the box?

Previously, you said they weren't. Where can I find aXML to test this?

Doing it like that would massively simplify the plugin code, and allow the two plugins to be completely de-coupled, and therefore usable with other plugins rather than only with each other.

If foo-bar definitely needs a certain specific input then it can just do some sort of validation check that it's input is acceptable before it runs, and return an error message if it isn't.

aXML doesn't work the way you think it does (or want it to), it's different and its the difference that makes it special. Understanding how to work with it and leverage it's properties requires you change the way you think. If you can't do that then that's not my fault or problem, and you can happily ignore it and carry on as you are, again not my problem, and not aXML's problem.

Perl doesn't interpret the output of programs written in Perl as potential code to parse for any Perl expressions. That difference is everything.