erusev / parsedown-extra

Markdown Extra Extension for Parsedown

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Static instance() method still returning Parsedown instance

younishd opened this issue · comments

Obviously, ParsedownExtra::instance() should return a ParsedownExtrainstance, but it actually returns a Parsedown instance (since the method was not overloaded), which is very confusing.

I spent 3 hours trying to figure out why the heck ParsedownExtra wasn't parsing the Extra syntax correctly. This inconsistent behavior is confusing and annoying.

$foo = Parsedown::instance();
$bar = ParsedownExtra::instance();

Anyone reading this code would assume that $foo is an instance of Parsedown and $bar of ParsedownExtra. Well, that's not the case and I was wondering if there was a good reason to do this.

It's no big deal, I changed the affected lines to:

$foo = new Parsedown();
$bar = new ParsedownExtra();

I'd suggest to either overload the instance() method to return the correct instance or to get rid of it altogether.

This is a good use-case for PHP 5.3+ late static binding. It could instantiate the class with new static() which would produce an instance of the class where the method was called, not where it was defined.

@hkdobrev Nice suggestion, thanks! Would you like to create a PR?

The tutorial on creating extensions fails due to this bug when using instance() as outlined in this stack overflow thread.

@hkdobrev Do you think you could create an MVP version of your PR - that is, just the change in Parsedown.php? I'm sure that the changes that the current version introduces make sense, but at this point, I don't have the time go through them :(

My PR is just the change in Parsedown.php, but properly tested. Basically you suggest to not test it.

@hkdobrev
No.
Your commit is changing 7 files. That's 6 files too many.
Also, your commit message is a lie: it says something about fixing the instance() issue, but you're also adding some random vendor folder to gitignore, messing up the travis file for some reason, removing empty lines in random files, adding unit tests all over the place (because unit tests are good, right?), and then you decide to add the empty test class to the composer autoloader, because using require to require is too mainstream nowadays.

@hkdobrev I understand that, but since these tests seem to add a lot to the repo, I need to get familiar with them and I don't have the time for that, so at this point, I'd prefer a PR that is just the change in Parsedown.php.

@erusev I've updated my PR with tests without using Composer for the tests autoloading.

@hkdobrev Thanks, merged.