A little bit of feedback

--xjyYRNSh/RebjC6o
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 18, 2021 at 07:59:12PM +0200, Moritz Bunkus via Matroska-devel=
 wrote:

> Personally I'm fine with refactoring and moving both libraries closer to
> more modern C++ standards. Within limits, of course, and we can certainl=
y
> talk about those limits.[1]
>
> What I do have an issue with is your long list of "before anyone can
> contribute, you should do this" and "you should really do that" etc. tha=
t
> you started this discussion off with. I get it, contributing in its curr=
ent
> form is really, really hard; the situation not welcoming to new
> contributors at all.

But you do acknowledge that there is a bit of a chicken-and-egg
problem here, don't you?  Contributing under such conditions is not
just hard, it's worse: A prospective contributor risks having to throw
away his work if he guessed the mode of proper contribution wrong.
Thus he won't ever do it, thus nothing will ever improve.

Also I wouldn't get hung up on using more modern C++.  That's the
least of problems.  It's far more important IMO that the libraries
become more comprehensible through better structure and naming of
concepts, definition of design and implementation
considerations/goals, and also deciding what is part of the API and
what is to be considered internal.

> But I simply have neither the time nor the motivation to tackle that lon=
g
> list. That's what I meant with "the libs are good enough for my use". I
> have more than enough on my plate with MKVToolNix & general spec work. I
> already have to leave so much stuff undone with those two that I don't w=
ant
> to take even more time away from them.
>
> What I would be fine doing includes: giving feedback on proposed directi=
ons
> for changes; explaining things from time to time if I know how they work=
;
> reviewing merge requests; testing merge requests with MKVToolNix.
>
> What I will not commit to includes: extending the test suite(s); writing
> documentation; writing a lot of code.

All that is fair.

> > * =E2=80=A6 Adding an intermediate class EbmlLeaf=E2=80=A6
>
> No need for a new class for that; a stand-alone function will do
> nicely. Wouldn't even have to be a function template.
>
> > * =E2=80=A6With an intermediate class pair EbmlLarge/EbmlSmall=E2=80=
=A6
>
> Stand-alone functions would suffice for this purpose as well.

Is there a reason for this seeming aversion to introducing new
classes?  If it is to minimize vtable look-up time then measurements
should be the arbiter in this question.  These new classes would be
abstract and needn't add any more code, but just more structure to the
hierarchy.  Being able to discern between subtly different things
using the compiler's type system strikes me as rather important not
just for catching logic bugs, but for idiomatically expressing one's
intentions.  And how else would you implement a method that should
only ever take a non-master as an argument (or return one) if you just
define a function to test for that?  Defining a dozen different ones
manually?  Currently you can only discern between EbmlElement,
EbmlMaster and the individual atomic Ebml datatypes.  You can do
almost nothing with that unless you write a ton of classifying code
manually.

Mandating underusing the type system like that would be a constraint
that would need some very, very good reason to justify it.  Merely
having to click more in the VS Code class browser, while annoying,
isn't a good enough one IMO.

> We've had the discussion about the minimum C++ version we'd like to supp=
ort
> last year. As VLC is still built with some older compilers, we settled o=
n
> C++11 for the time being. See here:
> https://github.com/Matroska-Org/libebml/issues/65

Pasting that into a file took 5 seconds.  The attached file also
summarizes what else I gathered so far.

Regards,
Dennis.

--xjyYRNSh/RebjC6o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=CONTRIBUTE
Content-Transfer-Encoding: base64

R3VpZGVsaW5lcyBmb3IgY29udHJpYnV0aW5nDQo9PT09PT09PT09PT09PT09PT09PT09PT09
PT0NCg0KKiBVc2UgcG9ydGFibGUsIGlkaW9tYXRpYyBDKysxMSBhbmQgb25seSB1c2UgY29u
c3RydWN0cyBzdXBwb3J0ZWQgYnkNCiAgdGhlIGNvbXBpbGVycyBvZiB0aGUgcGxhdGZvcm1z
IHRhcmdldHRlZCBieSBNS1ZUb29sTml4IGFuZCBWTEMsDQogIGkuZS4gaXQgbXVzdCB3b3Jr
IHdpdGggR0NDIDQuOS4gIFNlZQ0KICBodHRwczovL2dpdGh1Yi5jb20vTWF0cm9za2EtT3Jn
L2xpYmVibWwvaXNzdWVzLzY1DQoNCiogRmlsZXMgbXVzdCBiZSBVVEYtOC1lbmNvZGVkIGFu
ZCBpbmRlbnRlZCB3aXRoIFNQQUNFLCBub3QgVEFCLg0KDQoqIFN1Ym1pdCBjaGFuZ2VzIGVp
dGhlciBhcyBwdWxsIHJlcXVlc3RzIG9uIGdpdGh1YiBvciBvbiB0aGUgbWFpbGluZw0KICBs
aXN0IGFzIHNvbWV0aGluZyB0aGF0IHdvcmtzIHdpdGggImdpdCBhbSIuDQoNCiogQ29uc3Vs
dCB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSBhbnkgY2hhbmdlIHRoYXQgYnJlYWtzIHRoZSBB
Qkkgb3INCiAgQVBJLiAgSWYgeW91IHJlbmFtZSBzb21ldGhpbmcgZWl0aGVyIHByb3ZpZGUg
YWxpYXNlcyBvciAod29ya2luZyEpDQogIHBhdGNoZXMgZm9yIE1LVlRvb2xOaXggYW5kIFZM
QywgdG9vLiAgQXNrIG9uIHRoZSBsaXN0IGZpcnN0IGluDQogIGVpdGhlciBjYXNlIS4NCg0K
KiBZb3VyIGNoYW5nZXMgaGF2ZSB0byB3b3JrIHdpdGggYm90aCBWTEMgKGJvdGggZGV2IGFu
ZCBjdXJyZW50DQogIG1haW50ZW5hbmNlIHZlcnNpb24pIGFuZCBNS1ZUb29sTml4Lg0KDQoq
IERvbid0IG1ha2UgdGhpbmdzIHdvcnNlLiAgVGhhdCBtZWFuczoNCiANCiAgKyBObyBlZ3Jl
Z2lvdXMgdGVtcGxhdGUgZmVzdHMuDQoNCiAgKyBObyBCb29zdC4NCg0KICArIE5vIG5ldyBv
cGVyYXRvciBvdmVybG9hZGluZyAodW5sZXNzIHlvdSBwcm92aWRlIHdlbGwtcmVhc29uZWQN
CiAgICBhcmd1bWVudHMgZm9yIHdoeSBhbiBleGNlcHRpb24gc2hvdWxkIGJlIG1hZGUpLg0K
DQogICsgRG9uJ3QgYmx1ciB0aGUgbGluZSBiZXR3ZWVuIGxpYmVibWwgYW5kIGxpYm1hdHJv
c2thIG1vcmUuDQoNCiogTmVpdGhlciBleHRlbmQgbm9yIGNvbnN0cmFpbiB0aGUgc2NvcGUg
d2hpY2ggaXMgYXMgZm9sbG93czoNCg0KICAgIGxpYm1hdHJvc2thIGFuZCBsaWJlYm1sIHNl
cnZlIHRvIHByb3ZpZGUgdGhlIGJhcmUgcHJpbWl0aXZlcyBmb3INCiAgICBtYWtpbmcgTWF0
cm9za2EtbGlrZSBmaWxlcyBhdCB0b2xlcmFibGUgbWFpbnRlbmFuY2UgZWZmb3J0IHdoaWxl
DQogICAgYmVpbmcgY29uY2VwdHVhbGx5IGZpbmUtZ3JhaW5lZCBhbmQgZmxleGlibGUgZW5v
dWdoIHRvIGFsbG93IGJvdGgNCiAgICBNYXRyb3NrYSBhYnN0cmFjdGlvbnMgb2YgTUtWVG9v
bE5peCBhbmQgVkxDIHRvIHJlbWFpbg0KICAgIGluZGVwZW5kZW50bHkgbWFsbGVhYmxlIHRv
IGNhdGVyIHRvIGRpZmZlcmVudCBzdWJ0bGV0aWVzIG9mIHRoZWlyDQogICAgcmVzcGVjdGl2
ZSB1c2VjYXNlLiAgTW9zdCBpbXBvcnRhbnRseSwgbGlibWF0cm9za2EgZG9lcyBub3QgdHJ5
IHRvDQogICAgb2ZmZXIgYSBnZW5lcmFsLXB1cnBvc2UsIGVhc3ktdG8tdXNlIE1hdHJvc2th
IHJlYWRlci93cml0ZXIuDQoNCiAgWW91ciBhZGRpdGlvbnMgc2hvdWxkIGJlIHNtYWxsIGFu
ZCBzZWxmLW1haW50YWluaW5nLiAgVGhlIGluZXJ0aWEgb2YNCiAgdGhlIGxpYnJhcmllcyBh
cmUgdG8gYmUga2VwdCBzbWFsbC4gIElmIHlvdSBzZW5kIGtpbG9saW5lIHBhdGNoZXMgb2YN
CiAgYWRkaXRpb25zIHlvdSdyZSBsaWtlIGRvaW5nIGl0IHdyb25nLg0KDQoqIElmIHlvdSBy
ZWZhY3RvciBzb21ldGhpbmcgdGhhdCByZXN1bHRzIGluIHZlcnkgbG9uZyBkaWZmcywgc2Vu
ZCBhDQogIGRpZmYgZm9yIGEgc21hbGwgZmlsZSB0byB0aGUgbGlzdCBmaXJzdCB0byB0YWxr
IGl0IG92ZXIuDQoNCiogSXQncyB1bmxpa2VseSB0byBldmVyIGhhcHBlbiwgYnV0IGJlIG1l
bnRhbGx5IHByZXBhcmVkIHRvIG1haW50YWluIGENCiAgZm9yayBpbmRlcGVuZGVudGx5IGlu
IGNhc2Ugd2UgbmVlZCBzb21lIHJlYWxseSBiaWcgY2hhbmdlcyB3b3JrZWQNCiAgaW4uDQoN
CiogQWRkIG1vcmUgdGVzdHMgaWYgeW91IGNhbi4NCg0KKiBUYWtlIG5vdGVzIGFzIHlvdXIg
dW5kZXJzdGFuZGluZyBvZiB0aGUgY29kZSBpbXByb3ZlcyBhbmQgdHJ5IHRvDQogIHNoYXBl
IGl0IGludG8gZG9jdW1lbnRhdGlvbiwgaG93ZXZlciBydWRpbWVudGFyeS4NCg==

--xjyYRNSh/RebjC6o
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Matroska-devel mailing list
[email protected]
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

--xjyYRNSh/RebjC6o--