[go-nuts] Re: Proposal: return if any not nil
Ah, I just re-read the thread subject: if *any* of the values are non-nil.
Sorry for the misunderstanding.
On Friday, February 16, 2018 at 3:42:23 PM UTC-7, Paul Brousseau wrote:
>
> If all of the values are non-nil, then `retnn nil, err` would not return,
> would it? Did I miss something?
>
> On Friday, February 16, 2018 at 2:38:05 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi All,
>>
>> I've been contemplating alternative methods to address the "boiler plate"
>> of error handling in Go. One of the main benefits I see to the current
>> approach is that indentation highlights exception paths vs the success
>> path. From a readability perspective I can see the benefit of this
>> approach. It allows a reader to efficiently scan a function.
>>
>> One problem I see with the approach however is that it results in a lot
>> of vertical expansion in the code. If you take a fail-fast and return such
>> as the following it requires 4 lines of code for every check or worse
>> people ignore the error with an underscore.
>>
>> r, err := os.Open("blah.txt")
>> if err != nil {
>> return nil, err
>> }
>>
>> What I've been thinking about is a return statement that will return only
>> if all of the values are non-nil/blank.
>>
>> The statement would enable you to replace the above with a single return
>> as follows;
>>
>> r, err := os.Open("blah.text")
>> retnn nil, err
>>
>> I'm not wedded to the statement name retnn but more the general principle.
>>
>> Thoughts?
>>
>> Nathan
>>
>
--
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.
[go-nuts] Re: Proposal: return if any not nil
If all of the values are non-nil, then `retnn nil, err` would not return,
would it? Did I miss something?
On Friday, February 16, 2018 at 2:38:05 PM UTC-7, Nathan Fisher wrote:
>
> Hi All,
>
> I've been contemplating alternative methods to address the "boiler plate"
> of error handling in Go. One of the main benefits I see to the current
> approach is that indentation highlights exception paths vs the success
> path. From a readability perspective I can see the benefit of this
> approach. It allows a reader to efficiently scan a function.
>
> One problem I see with the approach however is that it results in a lot of
> vertical expansion in the code. If you take a fail-fast and return such as
> the following it requires 4 lines of code for every check or worse people
> ignore the error with an underscore.
>
> r, err := os.Open("blah.txt")
> if err != nil {
> return nil, err
> }
>
> What I've been thinking about is a return statement that will return only
> if all of the values are non-nil/blank.
>
> The statement would enable you to replace the above with a single return
> as follows;
>
> r, err := os.Open("blah.text")
> retnn nil, err
>
> I'm not wedded to the statement name retnn but more the general principle.
>
> Thoughts?
>
> Nathan
>
--
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.
[go-nuts] Re: Safe Packages
I think that might depend on what qualities you define as "safe"? On Monday, February 12, 2018 at 12:43:05 PM UTC-7, dc0d wrote: > > Is there a way to identify a package as safe? > > Let's restrict the imported packages to built-in ones. Now assuming a > package only imports "strings" and "net/url" can it considered as safe? > Since it does not (can not) modify the environment (most notably executing > code)? > > Of course the package still can behave in a malicious manner by (for > example) creating too many goroutines. > > This came to mind when I was reading about package managers and learnt > some problems that they have. > -- 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.
[go-nuts] Understanding how to use the "go/*" APIs
I am working on a program to consume Go source code and maintain a running state of that program as a user edits that source in an IDE. I have a working implementation that *loads* the program AST representation (inc. all imports and standard library) and runs it through a type checker, but my implementation is rudimentary (so much so that I'm hesitant to share the source at this point; it's not terribly readable right now). Once the program is loaded, I can do simple things such as locating where an Ident is declared, but I haven't worked through finding all references to an Ident yet. I have some fundamental questions before moving on to greater tasks (such as handling edits to the program files). I hope that some of the folks here can provide some insight. 1) My current implementation maintains a single `token.FileSet` for all files in the program, across all packages. Is this correct, or is it better to keep a file set per package? 2) Similar question for `types.Info`. I currently have a single instance that is shared among all packages, but the source code comments say that it holds data "for *a* type-checked package" (emphasis mine). Should I be keeping a single instance per package instead? 3) I am keeping a `types.Checker` per package, but even so, I can only check one package at a time. My program is highly concurrent, and as it turns out, one checker may consuming a package "A", while package "A"'s checker is processing some test files, which results in a concurrent read/write panic from a map. (I am checking files from `build.Package` in waves -- first all Go and Cgo files, then test files, and later I will add external test files.) Are there any strategies to improve concurrency here? I am thinking about keeping a `sync.RWMutex` per-package, which I would write-lock when a package is getting checked, and claim a read-lock when a package is returned from my `types.Importer` / `types.ImporterFrom` implementation. Does this seem like a reasonable strategy? 4) When going through the type checker, what is the relationship between * `type.Package` instances that are imported via my custom `types.Importer` / `types.ImporterFrom` implementation provides, * the non-package-local tokens & identifiers, * and the information that gets stored in the `types.Info`? The thing that I'm really trying to understand is, if I have a complete program representation, and an exported part of a Go source code file changes, what will be the impact on packages that consume it? I know that once I run the new file contents through `parser.ParseFile`, I will get a completely new `ast.File`, which I will have to type-check again to get a new `types.Package`. I don't want to walk the entire package dependency tree if a low-level package changes; are there ways to avoid that? Thanks for any insight. This is a pretty big & abstract subject matter to ask a bunch of questions about all at once, and I apologize if I'm breaking etiquette here. -- 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.
