On Thu, Oct 8, 2015 at 6:03 PM, Devchandra Meetei <[email protected]> wrote: > Hi libuvers > > While trying to come up wrappers, We sometimes feel accessing internal > member will ease our life. > Will there any any bad impacts for > >> uv_d_close(uv_d_t *d, uv_close_cb uv_cb) { >> d_close(d, d_cb); >> } > > we want to call uv_close with uv_cb as callback in d_cb. For this to happen, > we need to pass uv_cb. > > 1) We don't want to touch `void *data` of handle , should be reserved for > app writer > 2) We can introduce function pointer in uv_d_t struct, but that seems to be > a repeat and waste of memory. > > > So if we write >>void d_cb(uv_d_t *d, int rv) { > uv_close(d->uv_tcp_t_.close_cb, d->uv_tcp_t_.close_cb); >>} > >> uv_d_close(uv_d_t *d, uv_close_cb uv_cb) { >> d->uv_tcp_t.close_cb = uv_cb; >> return d_close(d, d_cb); >>} > > Will there be any bad impacts APART from depending on internal represenation > is bad, as implementation can change.
Well, it's not just that the internal representation can change, its meaning can change as well. If you're relying on implementation details, you're going to get burned sooner or later. Warranty void if seal is broken. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
