erusev / parsedown

Better Markdown Parser in PHP
https://parsedown.org
MIT License
14.74k stars 1.12k forks source link

Make it easier to add multiple extensions #686

Open Atulin opened 5 years ago

Atulin commented 5 years ago

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());
aidantwoods commented 5 years ago

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.

Atulin commented 5 years ago

Glad to hear it's on the roadmap 👌

aidantwoods commented 5 years ago

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

glensc commented 5 years ago

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.

aidantwoods commented 2 years ago

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!