I already have the patches out, I think jordan will get them reviewed and pushed this weekend.
On Fri, Apr 22, 2011 at 11:01 AM, Martin Logan <[email protected]> wrote: > I agree as well. Lets start re-factoring and then make sure that > moving forward that is the way we keep it. > > On Fri, Apr 22, 2011 at 9:44 AM, Jordan Wilberding > <[email protected]> wrote: >> I completely agree on all points. I think although not required, having >> specs for internal functions creates a more resilient code base that is less >> prone to errors. It forces you to think through the functions and allows us >> to use automated quality tools. >> As for exporting types. This needs to be required, without exception. I >> don't see any scenario where you export a function without all of it's >> associated types being exported as well. >> Thanks! >> JW >> >> On Fri, Apr 22, 2011 at 9:47 AM, Eric Merritt <[email protected]> >> wrote: >>> >>> Guys, >>> >>> The modules we have in erlware_commons, ec_semver, ec_strings, etc. >>> have great public APIs, but none of the internal functions have specs. >>> Yes we have said they are optional but encouraged and thats true. >>> However, not having them really interferes with dializers ability to >>> find issues and makes the code quite a bit less understandable. Its >>> less important in these projects where an individual owns them >>> (ciconia, sinan, etc) however, I think its pretty important for >>> dedicated libraries like commons. So, when you are reviewing code, >>> push back at least a bit, if you don't see specs on the majority of >>> the functions. The developer may have a good reason for not having >>> them, and if they insist on being lazy its ok (its optional after all) >>> but a little bit of push back should increase our quality here. >>> >>> Another big deal, is none of our stuff exports types and they should, >>> especially modules that actually implement types like ec_semvar, and >>> ec_strings. Exported types *are* part of the public api and if your >>> module has a distinct type you should be exporting it. I will try to >>> grab some time to fix this stuff this weekend but, going forward lets >>> try to have it in there. It is better to get in the habit of having it >>> there then having to constantly go back and add it. >>> >>> Eric >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "erlware-dev" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/erlware-dev?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "erlware-dev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/erlware-dev?hl=en. >> > > > > -- > Martin Logan > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/martinjlogan > http://erlware.org > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
