parsedown icon indicating copy to clipboard operation
parsedown copied to clipboard

Make it easier to add multiple extensions

Open Atulin opened this issue 7 years ago • 5 comments

Currently, the only way to register multiple extensions would be

class Foo extends ParsedownExtra {}
class Bar extends Foo {}
class Baz extends Bar {}
class Foobar extends Baz {}

ending in

$parsedown = new Foobar();

IMHO it's rather counterintuitive and counterproductive, especially compared to other solutions – like what Twig does, for example:

$twig = new Twig_Environment($loader);
$twig->addExtension(new Twig_Extensions_Extension_Text());
$twig->addFunction(new \Twig_SimpleFunction('asset', function ($asset) {
    return sprintf('/public/%s', ltrim($asset, '/'));
}));

I propose we should at least discuss the possibility of using a similar approach, i.e.

$pd = new Parsedown();
$pd->extend(new ParsedownExtra());
$pd->extend(new Foo());
$pd->extend(new Bar());
$pd->extend(new Baz());
$pd->extend(new Foobar());

Atulin avatar Dec 07 '18 22:12 Atulin

See also: https://github.com/erusev/parsedown/issues/534

This is definitely something that I want to address. I think I'd be looking at more of an interface based approach to "extensions" going forward as opposed to the current situation—these could be used in a way similar to how you've demonstrated, and we wouldn't need extensions to depend on each other in order to work within the same Parsedown instance. Related to this problem is the reason behind not releasing the improvements in the 1.8.0-beta* releases as stable: even though there are no breaking changes to the public API, there are breaking changes on the protected API level that do impact extensions. For this reason I think it is best that the encouraged way of developing "extensions" isn't writing literal class extensions, which don't have a clear API boundary about behaviour they can rely on across updates.

aidantwoods avatar Dec 11 '18 18:12 aidantwoods

Glad to hear it's on the roadmap 👌

Atulin avatar Dec 11 '18 23:12 Atulin

Once it's finished, this should be solved by: #685

aidantwoods avatar Jan 20 '19 19:01 aidantwoods

you can use decorator pattern until now:

class Extension1 {
   public function __construct($parent) {
      $this->parent = $parent;
   }

   public function bla($arg) {
     $res = $this->parent->bla($arg);
     $res = dosomething($res);
     return $res;
   }

   // proxy everything unknown to parent
   public function __call($method, $arguments) {
      return call_user_func_array([$this->parent, $method], $arguments);
   }
}
$parsedown = new Parsedown();
$ext1 = new Extension1($parsedown);
$ext2 = new Extension2($ext1);

this way the Extension1, Extension2 code does not have to be modified if you want to change the injected parser.

this is not ideal, you still need to modify extension1 and extension2 code at least once.

glensc avatar Mar 10 '19 20:03 glensc

It's not released yet, but I've explained a little how I think this will work going forward over in: https://github.com/erusev/parsedown/pull/708#issuecomment-944799267. Feedback welcome!

aidantwoods avatar Oct 16 '21 00:10 aidantwoods