[ExpiredLink]

Some stylistic remarks:

- _MxStringBuffer need not be defined in the header, a forward declaration would be sufficient (a.k.a. encapsulation).

- the two #defines can be removed form the header, too.

- I wouldn't try to typedef away a pointer (as in typedef struct _MxStringBuffer * MxStringBufferRef) but either use the pointer (MxStringBuffer* ) or create a handle: struct MxHandleStringBuffer { _MxStringBuffer * impl; };

[jaimzob]

Thanks, I'll patch this up when I have more time - though I'm not sure there's enough time in the world to fix my sloppy C code... ;)

[alexchamberlain]

Point 1 needs expanding... Assuming that you only need to access MxStringBuffer via a pointer, you don't need to include it in the header. However, this is somewhat deceptive and doesn't self-document. I don't think there is much advantage to it at all.

Edit: In fact, you must need the declaration to access the internals.

[haberman]

Structures that are kept opaque both enforce encapsulation and give binary/ABI compatibility for free. These are two very large advantages. The documentation of a type should come from the supported operations you can perform on it, not the way it represents its data internally.

[ExpiredLink]

When you put the definition of _MxStringBuffer into the *.c file you can "access the internals". The advantage of forward declaration is encapsulation.

[gravitronic]

Pretty jerk response to someone sharing something for free.

It's on github. Post a pull request or keep it to yourself. Especially as your comments are stylistic.

[dpark]

Why is it a jerk response? He took the time to look at the code and offer suggestions. That hardly seems like a negative thing.

[gravitronic]

If I was sharing code and the response I got was "you should dot your i's and cross your t's" instead of "thanks for providing functional code for free" it would make me reconsider sharing more in the future.

[jaimzob]

Meh. I'm sure his comment was well-intentioned: If you spend most of your time communicating with computers then your communication with humans can sometimes tend toward the 'abrupt', after this long in the industry I'm pretty used to it.

[ExpiredLink]

> Meh. I'm sure his comment was well-intentioned

I'm surprised about the possibility of misunderstanding.

BTW, the code is 'open source' and copyrighted: I have found no license to use it freely.

[dpark]

The honestly, maybe you just shouldn't be so sensitive. The suggestions made were not harsh or insulting. If this kind of gentle feedback is so hurtful, then not sharing code is probably the right choice for you.

[pasbesoin]

Part of the assumption demanded by and centrally beneficial to HN, is that we are adults here and can approach critical review looking for its constructive nature and well-meaning aspects. HN has greatly benefited from countless individuals, both commentors and recipients, being willing to see or assume that such comments are not personal.

(As one other reply has put it, "constructive criticism".

In this case, the great-grandparent is free to reflect upon the g.p response, or not, depending upon their inclination and time. Perhaps it sparks further refinement; perhaps not. But I don't see it as being personally critical; to reiterate, it offers a perspective of possible refinement.

In the past some months, I've noticed the tone of comments on HN becoming more "emotional". That, I believe, is a slippery slope for the community. HN seems to function best when we all exercise emotional restraint, along with our technical and professional enthusiasm.

With regard, and hopefully not "calling out" the parent too much (or at all) in what I have taken primarily as an opportunity to make a more general comment.

[mikeash]

Excuse me? His response was nothing but polite and a perfect example of constructive criticism.