in reply to Re^18: Is an aXML compiler possible?
in thread Is an aXML compiler possible?

I already mentioned the possibility of post-inclusion to cover that.

Yes, it's the third or fourth time you mentioned it, and it's the third or fourth time I've told you it's completely useless. If I'm writing a plugin for someone else, I can't rely on there being a file at common/lab.

With the source of present_code looking something like this:

If you have to tell me what it *might* look like, I can't rely on the user of my plugin to have it, so I can't use it. Useless.

You really should read that to which you reply. It would save you a lot of time since you keep writing huge posts that address the issue I keep raising. You keep assuming one plugin has knowledge of what other plugins are available and an initimate knowledge of what they do (even though you keep saying people can and should just change how plugins behave willy-nilly).

Replies are listed 'Best First'.
Re^20: Is an aXML compiler possible?
by Logicus (Initiate) on Oct 31, 2011 at 19:10 UTC

    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... and letting end Perl programmers write whatever modules they want "willy-nilly".

      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) ...

        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'; } };

        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>

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


      Improve your skills with Modern Perl: the free book.