Question : how to work with multiple extends ?

[cavo789]

Hi all,

I didn't see directly how can I work with multiple extensions.

I'm using https://github.com/leblanc-simon/parsedown-checkbox/blob/master/ParsedownCheckbox.php of Simon Leblanc.

In my PHP, I've thus :

$parsedown = new ParsedownCheckbox();
$html = $parsedown->text('......');

and it works like a charm, great.

I've also an another extend to handle image's size :

class myOwnExtend extends ParsedownExtra
{

}

And it works but ... checkbox no more. It's quite logic since my call is

$parsedown = new myOwnExtend ();
$html = $parsedown->text('......');

myOwnExtend doesn't know anything about ParsedownCheckbox since, the tree structure is something like this :

parsedown
      | ----       parsedownExtra
                             | ----       ParsedownCheckbox
                             | ----       myOwnExtend 

The solution would be, I suppose,

class myOwnExtend extends ParsedownCheckbox

But I don't really want this because I can have several extensions... and ParsedownCheckbox can't be removed f.i.

Do you see a solution ?

I would like to call "as many" extensions I've of parsedownExtra ?

Thanks for your help.

[aidantwoods]

You could probably hack it together by creating an additional pseudo-base that acts as a middleman to perform late dependency inversion (i.e. it is constructed using an array of objects that also extend Parsedown).

The goal would be to rebuild some of the central "interface" to route markers to handler implementations in various Parsedown extensions.

You could then utilise the reflection API to break the protected access level constraint and pull out the required meta-data dependencies that you'd need to send markers to their handlers (i.e. you'd need to pull out the $BlockTypes, and $InlineTypes arrays as well as the respective marker lists (you could probably just build this from the array keys), and any other metadata). You'd also need to use the reflection API to pull out the block* and inline* methods and change their access level so you can call them (or probably just converting them to a bound closure would suffice). Ensure that your marker-handler arrays are able to reference these implementations.

Lastly you'd need to implement your own handler calling methods (line, lines, element, (probably li too) etc...) so that they know how to use your new class and can defer correctly using the differently built arrays.
Don't forget to also apply the above re-routing of calls for the Parsedown base class if necessary.

All this glossing over potential recursion in specific extensions that might make you unable to apply the mix of markdown flavours in certain areas where recursion occurs (since they may defer directly to their own line method for example), or how to choose between implementations when inline/block definitions conflict.

This is quite a bit of work for something that won't likely work very well, but it's an approach anyway 🤷‍♂️ .

[cavo789]

Hi Aidan

Thank you for your answer. I've probably just understood 10% of it; please excuse me.

It seems to be a huge work for, just, not write "class myOwnExtend extends ParsedownCheckbox" (in my example). If I need to hack classes of others authors, I don't win something...

In fact, I was searching something like a plugin's approach i.e. writing a PHP class that will be called by the master class (parsedown).

Thanks anyway for your very long and detailled answer.