Hacker News new | past | comments | ask | show | jobs | submit login

Although this is only a handful of lines [0] it's nice to design things well.

- By providing a 'builder' you add a clear API to the struct object's constructor. It doesn't make any more or fewer claims of capibility than it needs to. By exposing the internal storage you break that level of abstraction.

- Even assuming that the JS object type _is_ ordered, the ADT of the Struct type may be subtly different to the ADT of the object. By coupling the two you may prevent future flexibility.

- To that point, the 'field' method _does_ do something with each invocation (forceEndianess) as it adds it to the internal storage. If you passed in a map object it would still need to traverse each key to do that work, which (knowing JS objects) might make it more complicated.

[0] https://github.com/francisrstokes/construct-js/blob/master/s...




You seem to assume that the passed-in object should also be used as the resulting object. This is false, as they can be decoupled.

In other words, it's still possible to pass in a separate js object instance containing the configuration.

Yet I'm not sure about the whole of your arguments, so I can't tell if it would actually make sense to wrap the default js builder pattern implementation (the javascript object initializer syntax aaaaaaaaaaab refers to).

However, I do method builders often overused in API's where a simple singular builder method combined with builder classes suffice and simplify.


Agreed to an extent. But what if you want to extend the API to include the same field twice (for example). The semantics of the input object would prevent that.

I'm reluctant to spend too much time arguing over a fine point. It could be done one way or the other. I was just addressing aaaaaaaaaaab's question.


Really well put!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: