Re^2: What's the best way to use Any YAML (not YAML::Any)

Thanks. A couple of comments:

Checking for Dump/Load is prudent, but all of the listed YAML modules implement the common Dump/Load API, so I don't think it's absolutely necessary.
The check for Dump/Load in your last version assumes the included module uses @EXPORT. I wouldn't rely on that, as there are alternates to Exporter which don't use that, and while these modules might currently use it, that behavior is not in the API. If they switch to something else, this'll break.
A better way might be to perform an explicit import, e.g. something like
```
eval { $yaml_class->import( 'Dump'); 1; }
  or croak( "Can't find Dump in $yaml_class\n" );
[download]
```
or, if you can trust that the function isn't AUTOLOADED, look at the module's namespace for the function
```
Package::Stash->new( $yaml_class )->has_symbol( '&Dump' )
  or croak( "Can't find Dump in $yaml_class\n" );
[download]
```
The only foolproof method is to just wait for a runtime error:
```
my $Dump = $yaml_class . "::Dump";
[... later in the code ...]
my $var = eval { &$Dump(...) } or croak( "bad return or Dump not imple
+mented\n" );
[download]
```

There's also another problem, which I didn't recognize until late last night (and didn't get around to posting about before your reply), namely that if there's a YAML module already loaded, it should use that. I've updated the OP above to illustrate my current code.

Comment on Re^2: What's the best way to use Any YAML (not YAML::Any) Select or Download Code

Replies are listed 'Best First'.
Re^3: What's the best way to use Any YAML (not YAML::Any) by kcott (Archbishop) on Mar 15, 2014 at 21:35 UTC
"Checking for Dump/Load is prudent, but all of the listed YAML modules implement the common Dump/Load API, so I don't think it's absolutely necessary." Can you guarantee that you'll only ever use "the listed YAML modules"? Can you guarantee that you'll never want to use another function beyond `Dump` and `Load` in this, or a subclassed, module? Yes, it's prudent. No, it's not absolutely necessary. It's two lines of code that you can choose to add to your module or not. "The check for Dump/Load in your last version assumes the included module uses @EXPORT." No, that check occurred in the original version, not the update. The original solution was hidden in a spoiler (for anyone interested in seeing the changes that were made). I thought that "original solution (see spoiler below)" made this clear but apparently not: I've added additional text making this clearer. -- Ken	[reply] [d/l] [select]
Re^4: What's the best way to use Any YAML (not YAML::Any) by djerius (Beadle) on Mar 17, 2014 at 17:56 UTC
Can you guarantee that you'll only ever use "the listed YAML modules"? I can guarantee that all modules in the list have Load & Dump. If one doesn't, my module can't use it, so it won't be in the list. If I were to use a proxy module which didn't guarantee that API, I would have to check for it. The only one that I know of, YAML::Any, does offer that interface. Can you guarantee that you'll never want to use another function beyond Dump and Load in this, or a subclassed, module? I can guarantee that my module will only ever use Load & Dump. I can't say anything about subclasses, but if they need a particular API, they'll have to ensure that it is met. No, that check occurred in the original version, not the update. The original solution was hidden in a spoiler (for anyone interested in seeing the changes that were made). I thought that "original solution (see spoiler below)" made this clear but apparently not: I've added additional text making this clearer. For some reason, I was unable to view the code in the spoiler: clicking on the link didn't reveal it properly; I obviously commented on the wrong code. My apologies for the confusion. Thanks for your input.	[reply]


P is for Practical
	PerlMonks