I think we’ll just agree to disagree.
> On Feb 5, 2019, at 2:52 PM, Burak Serdar <bser...@ieee.org> wrote:
>
>> On Tue, Feb 5, 2019 at 1:46 PM Robert Engels <reng...@ix.netcom.com> wrote:
>>
>> If the error doesn’t know what it is wrapping but the caller needs to know
>> the wrapped error you have a design problem. It breaks all sorts of ‘isa’
>> semantics.
>
> This happens if you're using multiple layers of libraries that don't
> know about each other. It is not a design problem.
>
>>
>> If you need to know the internal buffer length, you have a design problem.
>> What if the wrapped buffer was unlimited or dynamic - there is no length to
>> return - you must read until eof.
>
> Sometimes you need to know the internal buffer length if you're
> dealing with a service behind a peculiar http front-end, like some
> akamai services. You have to send the content length, and if you know
> it already, you should be able to get it.
>
>>
>> It is not a matter or OO purity, it is a simple matter of encapsulation, and
>> not requiring upper layers to know and understand - or even have access to -
>> internal details.
>
> Encapsulation is useful if you're hiding internal details. But some
> internal details are not so internal under different circumstances,
> like the length of a buffer.
>
>>
>>>> On Feb 5, 2019, at 1:37 PM, Burak Serdar <bser...@ieee.org> wrote:
>>>>
>>>> On Tue, Feb 5, 2019 at 12:22 PM Robert Engels <reng...@ix.netcom.com>
>>>> wrote:
>>>>
>>>> As far as the error handling, this is kind of a limitation of the error
>>>> interface in Go and should be solved there. But I would start with asking,
>>>> why do you need the causation error? If it is increased logging, then the
>>>> higher level error should be able to represent the additional detail when
>>>> it is logged. If it is for control flow, then the containing error should
>>>> adequately represent the error.
>>>
>>> That's not always possible if the containing error doesn't really know
>>> what it is wrapping. The nested error could be of different types that
>>> the wrapper don't know about.
>>>
>>>>
>>>> If you are exposing the length of the underlying buffer higher levels,
>>>> that is a design problem. In the Nopcloser you are exposing the reader the
>>>> caller already has access to by way of the Reader interface. The Closer is
>>>> a decorator. You don’t have access the possibly real Closer in the
>>>> original implementation. There is no GetWrappedCloser.
>>>
>>> Note that the inability to expose the underlying buffer length is the
>>> problem here. The only safe way to get the length of the buffer, in
>>> this case, is to copy it.
>>>
>>>>
>>>> I would also argue that Nopcloser is a poor design. You are passing a
>>>> object around where the Close that the object is exposing is no longer
>>>> called. This can lead to very brittle code and obscure bugs - the object
>>>> is no longer behaving the way the designer expected. The Closer interface
>>>> expects that the resource will be closed, this is now broken.
>>>
>>> You are approaching this as an OO-purist. In my opinion, NopCloser is
>>> a simple adapter that wraps readers without a close(). If it wasn't in
>>> the library, it would've been rewritten in many projects.
>>>
>>>>
>>>> Much of a Gos dynamic interfaces though work poorly this way... but that
>>>> is another discussion.
>>>>
>>>>>> On Feb 5, 2019, at 12:33 PM, Burak Serdar <bser...@ieee.org> wrote:
>>>>>>
>>>>>> On Tue, Feb 5, 2019 at 11:27 AM Robert Engels <reng...@ix.netcom.com>
>>>>>> wrote:
>>>>>>
>>>>>> But even then, exposing internal details outward leads to lots of
>>>>>> problems, testability for certain. There’s almost always a better way
>>>>>> then GetNested, GetWrapped, or any of its derivatives.
>>>>>
>>>>> How so? How would you deal with something like error wrapping, for
>>>>> instance? Or in this specific case, how would you get the length of
>>>>> the underlying buffer if you wrap the reader with a NopCloser?
>>>>>
>>>>>>
>>>>>>> On Feb 5, 2019, at 12:20 PM, Robert Engels <reng...@ix.netcom.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Then you want inheritance not encapsulation.
>>>>>>>
>>>>>>>>> On Feb 5, 2019, at 10:46 AM, Burak Serdar <bser...@ieee.org> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Feb 5, 2019 at 9:41 AM Robert Engels <reng...@ix.netcom.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> GetNested anything is a sign something is broken in the API. The
>>>>>>>>> whole point of being nested is almost always encapsulation and then
>>>>>>>>> you are breaking it.
>>>>>>>>
>>>>>>>> That's too much of a generalization in my opinion. This is more like
>>>>>>>> decoration, adding new functionality at every layer, but there is no
>>>>>>>> way to expose all the functionality of the nested thing, so you need
>>>>>>>> to expose the thing itself.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On Feb 5, 2019, at 10:30 AM, Burak Serdar <bser...@ieee.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 5, 2019 at 9:12 AM <matteo.biage...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I've the following situation:
>>>>>>>>>>> I proxy a request to another server and when I made a POST and
>>>>>>>>>>> create a new request, the contentLength is zero:
>>>>>>>>>>>
>>>>>>>>>>> req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
>>>>>>>>>>> fmt.Println("New request from body:", req2.ContentLength) //
>>>>>>>>>>> print 0
>>>>>>>>>>>
>>>>>>>>>>> Checking in the source code of the NewRequest func Body don't
>>>>>>>>>>> respect some interface and populate the ContentLength field.
>>>>>>>>>>
>>>>>>>>>> When the first request is created, req.Body is set to a NopCloser,
>>>>>>>>>> and
>>>>>>>>>> that doesn't match any of the cases in the second NewRequest. For
>>>>>>>>>> this
>>>>>>>>>> to work, I guess the best way is to get the body length and set it
>>>>>>>>>> explicitly after constructing the second request.
>>>>>>>>>>
>>>>>>>>>> I don't know if this is intentional or not, but in general, it might
>>>>>>>>>> be a good idea to add a ReaderWrapper interface to the standard
>>>>>>>>>> library that defines a GetNestedReader() io.Reader function to access
>>>>>>>>>> the real reader from these utility classes.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could be a bug? Which could be a valid approach in order to create
>>>>>>>>>>> a new request from an existing one and correct set the Body length?
>>>>>>>>>>>
>>>>>>>>>>> A working example here:
>>>>>>>>>>>
>>>>>>>>>>> https://play.golang.org/p/SvCDLj0NrXb
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>>>> Groups "golang-nuts" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>>> send an email to golang-nuts+unsubscr...@googlegroups.com.
>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>>> Groups "golang-nuts" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>> send an email to golang-nuts+unsubscr...@googlegroups.com.
>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "golang-nuts" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "golang-nuts" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
