-1

I contribute to an open source webgl library. A PR has been proposed that solves a problem, introduces a new feature to the library, and places some properties on some class FOO.

I didn't like the placement of that property as i feel it' better suited for BAR. The pattern can be seen as an anti-pattern according to some principles.

I checked out the branch from the PR, refactored it the way i suggested and ended up with 30% less code, and 30% less files being touched, while not breaking the pattern related principles.

I was told that in the case of this library, it's valid to not follow the principle.

I'm a bit confused by the rejection of such an argument (follow a principle). I thought that literature can be cited as sort of an absolute truth, proof.

How can i address this and what should be my expectations?

I can see:

Well, several decades of CS research seems to disagree with you

As offensive.

  • 1
    Wonder if the PR would've been accepted if you hadn't offered it up as a solution to a violation of a best practices guideline and instead just offered it up as a reduction in code size and complexity ... – ivanivan Jun 15 '18 at 18:08
  • unfortunately not, i reached out to academia as a last resort – pailhead Jun 15 '18 at 18:21
  • It was argued that despite the code reduction, the pattern goes against the (anti?) pattern of the library already in place. .foo, .bar and .baz have historically been scattered between super and sub classes, in order to keep it consistent, it shouldn't be applied to .baz straight away. The argument is for a larger PR to address the placement of all the props that may be misplaced. But this i think would move much slower than just properly placing a new one in the first place. – pailhead Jun 15 '18 at 18:24
  • Why the downvote, can you help improve the question or state why it should be removed? – pailhead Jun 15 '18 at 18:25
  • 3
    I'm voting to close this question because it is asking us to weigh in on a technical discussion that is completely orthogonal to open source development, and therefore off topic. – amon Jun 15 '18 at 18:29
1

I thought that literature can be cited as sort of an absolute truth, proof.

Honestly, that's ridiculous. Just like anything else, SOLID is a set of guidelines which have been found to be generally applicable and useful - but not universally. It may be the are good reasons to break the guidelines in the case.

For what it's worth, what you're doing here is argument from authority.

  • en.wikipedia.org/wiki/SOLID – pailhead Jun 15 '18 at 17:47
  • Is there more of a burden on one side? Everything i read was formatted in such a way to make it sound that breaking away from any such principle is the thing that needs to be justified, while just adhering to the principle does not. – pailhead Jun 15 '18 at 17:49
  • What else can i use to say There aren't good reasons to break the guidelines in this case if not cite the academic guideline? – pailhead Jun 15 '18 at 17:49
  • 2
    Practically, the burden is on the person without commit permissions to convince the person with commit permissions. You can argue academic points about where the burden "should" lie as much as you want, but you won't even get fake Internet points for it. – Philip Kendall Jun 15 '18 at 17:54
  • 1
    @pailhead: No, the codebase is not doomed, but such refactors will not be easily accepted from random committers. To refactor the codebase in such a way, you would first need an agreement among the maintainers that it is a good idea (and it helps your case if you have a good reputation among them) and a plan how to go about it (i.e. one big commit, or multiple small ones; which area's to tackle first, etc.). – Bart van Ingen Schenau Jun 16 '18 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.