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?

I never said you needed to do anything of the sort.

As for the specials, prior to you isolating the example of needing them in those rare special cases, I had never really paid them much attention or even felt any need to. The e-commerce site didn't need to output aXML (or perl code), neither did the auctions site, or the forum system.

I find it rather bizarre your so fixated with them, since they are such a rarely needed thing in real world applications.

However having said that I do recognise that for the solution to be absolutely complete that there needs to be a standardised solution to this, such that PerlNights will be able to input, store and output absolutely any string, even strings containing the specials themselves.

When I'm completely happy that I have an infallable solution to it I will document it properly and you will have a static final answer, until then and until the new version is finished complete with said solution, whatever is said about it is subject to change if or when a fault is found, or even if I change my mind about it. (my perogative, my language)

Note; the problem and solution exist at the level of the perl and the plugins, not at the level of the aXML document, and any criticism that is levelled along these lines is a criticism of the perl implementation of aXML and not of aXML itself.

The version I have at the moment is capable of outputting long and complex aXML strings correctly, and even source highlighting them (wanna see a screen shot?). But when it comes to outputting Perl code, specifically, and only, Perl code which uses the specials, it breaks and I'm currently working on that issue, rare as it is, because I want the implementation to be 100% perfect, not merely 99.99999% perfect.

So unless your going to tell me that it is impossible to solve the problem, (ie, that Perl itself cannot do it) then perhaps it would be more useful to focus on something else until I have fully solved it? If you are going to tell me it's impossible, then I'm sorry but I'm not just going to take your word for it until I have fully exhausted every trick I can think of to do so. (such is my faith in Larry)

If I do find out it's totally impossible, the ketchup bottle will be fetched from the fridge, and I will be offline for a while with a severe stomach ache.

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.