Re^5: Factory classes in Perl

> Code that will use a module to do amazing things if it's installed, but will muddle through with some lesser code path if that dependency is missing or unavailable on the system"

Do you know Term::ReadLine ?

Perl interface to various readline packages. If no real package is found, substitutes stubs instead of basic functions.

I have to say it was very confusing for me to see features of the debugger documented ... And they simply don't work, because the right backend is missing or can't be installed.

Well it still is confusing.

But overload has a good example for fall backs.

If ".=" isn't overloaded it will fall back to the overload for "." and this will fall back to "" for stringification.

So it's possible to work with lesser code.

> > Part of the problem here is that most of the literature for factory classes will be written with JAVA like languages in mind. Perl is far more TIMTOWTDI.

> I agree. Although I'm far from an expert on the theory, I think Dependency inversion principle is probably an interesting and relevant read.

Well I tried to read thru all those https://en.wikipedia.org/wiki/Creational_pattern and I'm a bit lost.

I don't think they translate well to Perl, that's mainly "Meta Programming" in Perl.

It's like explaining English with alien grammar. How do you explain Latin's Locative case to people who already struggle to use "whom" even after "to" or "for" in accusative or dative cases (that's direct and indirect object, folks ;).

So without really deeply knowing Java and UML I can't fully decipher it.

ANYWAY

I read the OP's example again, and it seems to explain how to write a test suite that adapts to an application with various "Deer" plugins.

It's not up to the test suite to install the plugin it has to react to the given environment.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^5: Factory classes in Perl Select or Download Code

Replies are listed 'Best First'.

Re^6: Factory classes in Perl
by haukex (Archbishop) on Jan 14, 2021 at 15:50 UTC

Well it still is confusing.

That sounds to me like you agree that such "lesser code paths" like the stubs in Term::ReadLine are problematic ;-)

overload ... So it's possible to work with lesser code.

I don't think that's the same thing. The option fallback could have been given a better name, since what is's actually controlling is "magic autogeneration", and the operations it generates oftentimes Do The Right Thing. Plus, it has nothing to do with dependencies.

I don't think they translate well to Perl, that's mainly "Meta Programming" in Perl.

Yes, I think there are quite a few of these concepts that we don't see too much of in the Perl world. Although I haven't used it myself, my understanding is that Bread::Board is a Perl implementation of some of these concepts.

It's not up to the test suite to install the plugin it has to react to the given environment.

Well no, but my points above still stand: summarized, I personally think it's better if the module's behavior and tests are as deterministic as possible, instead of depending on whether or not a module is installed in the user's environment.

[reply]
[d/l]
[select]


Clear questions and runnable code get the best and fastest answer
	PerlMonks