Open Atulin opened 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.
Glad to hear it's on the roadmap 👌
Once it's finished, this should be solved by: #685
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.
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!
Currently, the only way to register multiple extensions would be
ending in
IMHO it's rather counterintuitive and counterproductive, especially compared to other solutions – like what Twig does, for example:
I propose we should at least discuss the possibility of using a similar approach, i.e.