+toerror

[ingun37]

Hi! it's been a while since we talked about "BoolToError" from the Issue. It's my first pull request to any repository ever, so hope u understand if there's any clumsy mistake 😅 Also I don't know how to handle correctly that the import path in main.go being generated pointing to my forked go package "github.com/ingun37/goderive/plugin/toerror" not "github.com/awalterschulze/goderive/plugin/toerror", so I hope you can help me on that. I'll be waiting for your feedback thank you

[awalterschulze]

If this goes well and you want to contribute more. I think we can come up with many more ideas. Just let me know.

[ingun37]

I improved overall comments, fixed import path, made it to accept functions with any parameters, added test code.

[ingun37]

I don't think catching panics is deriveToError's job but it sounds very interesting. It's actually one of things I thought would nice to have one using goderive! I'll think about that.

[awalterschulze]

Great work :)

You should replace me with yourself as the Copyright of the files you created.

I would like to also solve the apparent Merge Conflict that github is reporting. What version of go are you running?

Could you run make travis on your computer and update the diff?

[ingun37]

I'm using go1.10.4 test/normal/derived.gen.go in my branch has been already generated by make so make travis isn't making any difference.

[ingun37]

It was a very trivial conflict (line competing with empty line). I followed the github guideline and now I think the conflict is gone?

[awalterschulze]

Thank you so much, this looks great :)

Oh wait I forgot the most important part. The readme.md needs to be updated. Please add your function to the function list.

If you want to add an example that is also great, but it is optional. https://github.com/awalterschulze/goderive/blob/master/Contributing.md#contributing-examples

[ingun37]

As working on example, found a couple of bugs and fixed it. Added example. One thing I'm concerned is that the documents may has been written poorly because of my english.

[awalterschulze]

Don't worry about your english, it looks great, I haven't noticed any lack of skill, but then again my english is also not that great :)

[ingun37]

As working on more examples and tests I got thinking that.. It's obvious that map-indexing and type-assertion will be the significant two in practice. But since they are syntax not a function, you gotta interpret them into function first; that would be same old tedious repetitive codes for every types; exactly what you tried to repel by using Goderive.🤔

So I want to support following 2 more signatures to make deriveToError more practical.

deriveToError(error, map[A]B, A) (B, error)//map indexing.
deriveToError(error, A) (B, error)//type conversion

First one (map indexing) will be no problem. But for the second one (type assertion) the returning type (B) has to be inferencable without any parameter of B... is it possible? is there a history or code I can reference for such case? Or any other opinion? Like it should be seperated to another function like..deriveComposableIndexing or deriveComposableTypeAssertion.... or let's not get too practical and let's focus and finish deriveToError first?

[ingun37]

Let's move on without regarding map-indexing/type-assertion extension. They could be out of scope of deriveToError I've resolved the example issues.

[awalterschulze]

I have also been thinking about assertions and gets from a map and was thinking of something like:

deriveGet(m map[a]b, a) (b, bool)
deriveGet(c chan b) (b, bool)

Type assertions are much harder and I don't have an idea yet. What I want is:

deriveAssert(v, float64) (float64, bool)

But that is impossible. For assert it might be easier to use a library that has loads of assert functions like:

assertFloat64(v interface{}) (float64, bool)

But I don't know

[ingun37]

I improved toerror to accept any return type. (previously accepted only a tuple length of 2) Example now demonstrates composability of toerror Better testing code.

[awalterschulze]

I think we are ready to merge :) Are you happy?

[ingun37]

Sure :)

[awalterschulze]

Thank you so much for this new function, I think this really fits in well with the mission :)

[awalterschulze]

Let me know if you want to discuss more on get and assert.

Also I saw you did quite a bit of category theory for programmers. I am getting stuck on universal construction. Do you have any tips or other resources that explain this differently?

[ingun37]

I myself have trouble understanding overall category theory let alone universal construction 😂 But I think Cakes, Custard and Category Theory's universal properties chapter builds excellent intuition about universal property/construction. But it's bare intuition, nothing technical.

[awalterschulze]

Thank you. I'll try that. I added it to my list :) https://github.com/awalterschulze/learning/blob/master/Mathematics.md

[awalterschulze]

I think universal construction is the key part of category theory and without it, I can only imagine the parts that I understand.

[ingun37]

I just saw your works on mathematics WOW 🙌 I admire your enthusiasm and devotion to learning you seem to be a really good developer

[awalterschulze]

I admire your devotion to learning and hope to one day catch up. You'll see that most of the list does not have a lot of check marks :( I still have a lot to learn. I feel that I missed something while at university.

Current development feels like hacking, compared to the math we could be using. Maybe one day I will learn how to develop, until then I will continue hacking for money and fun :)

[ingun37]

Yeah, I feel what I develop very temporary and little, compared to timeless rigorous math. I can only keep learning :)