Re: [go-nuts] Expiring map

2017-07-20 Thread Rajanikanth Jammalamadaka 
Thanks for the replies.

Sameer: it would be awesome if you can open source them.

Thanks,
Rajanikanth

On Thu, Jul 20, 2017, 7:47 PM Sameer Ajmani  wrote:

> We have a few implementations of this inside Google (expiring.Map,
> timedcache, and lru.Cache).  It might make sense to open source these, if
> they have no internal dependencies.
>
> On Wed, Jul 19, 2017 at 3:22 PM Rajanikanth Jammalamadaka <
> rajanika...@gmail.com> wrote:
>
>> Does somebody have a recommendation for an expiring dict? If I have to
>> write my own, is there a way to avoid iterating over all the keys to delete
>> the expired entries?
>>
>> Thanks,
>> Raj
>>
> --
>> 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.

Re: [go-nuts] Expiring map

2017-07-20 Thread Sameer Ajmani 
We have a few implementations of this inside Google (expiring.Map,
timedcache, and lru.Cache).  It might make sense to open source these, if
they have no internal dependencies.

On Wed, Jul 19, 2017 at 3:22 PM Rajanikanth Jammalamadaka <
rajanika...@gmail.com> wrote:

> Does somebody have a recommendation for an expiring dict? If I have to
> write my own, is there a way to avoid iterating over all the keys to delete
> the expired entries?
>
> Thanks,
> Raj
>
> --
> 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.

Re: [go-nuts] IsZero

2017-07-20 Thread Ian Lance Taylor 
On Thu, Jul 20, 2017 at 2:50 PM, Helton Marques  wrote:
>
> Yeah, I now, but considering these proposal:
> https://github.com/golang/go/issues/20757
> This function (IsZero) would not bring even more reliable use ?

Sure, if we adopt proposal #20757 we may well need or at least want an
IsZero method.  That is a Go 2 proposal, though; for Go 1 I don't see
sufficient benefit.

Ian

-- 
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.

Re: [go-nuts] IsZero

2017-07-20 Thread Helton Marques 
Yeah, I now, but considering these proposal: 
https://github.com/golang/go/issues/20757 
This function (IsZero) would not bring even more reliable use ?

Em quinta-feira, 20 de julho de 2017 22:12:04 UTC+2, Ian Lance Taylor 
escreveu:
>
> On Thu, Jul 20, 2017 at 1:02 PM, Helton Marques  > wrote: 
> > 
> > There's some reason to not have the function `IsZero` to time.Duration ? 
> > 
> > IMO, I think this can be useful: 
> > 
> > 
> > ``` 
> > type Server struct { timeout time.Duration `yaml:"timeout:"` } 
> > ... 
> > if srv.timeout.IsZero() { srv.timeout = defaultServerTimeout } 
> > ``` 
> > 
> > Anyone knows if there's some restriction to not have IsZero() bool 
> functions 
> > to defined types as int64 ? 
>
> Where you want to write `d.IsZero()`, you can just write `d == 0`. 
> I'm not sure adding a `IsZero` method is really worth it. 
>
> Ian 
>

-- 
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.

Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

2017-07-20 Thread Jesper Louis Andersen 
On Mon, Jul 17, 2017 at 11:07 AM  wrote:

> does it make sense to consider a "value type of any type that carries out
> its input type" ?
>

Yes. This is called a "universal" and is related to the concept of
parametrization by J. Reynolds.

Your 'do' function is often called 'id' for the obvious reason that it is
the identity function. In SKI logic it is the I combinator. If we annotate
the type as you would in type theory, you would write something like

id : (T : Type) -> T -> T
id t x = x

to say that the function can be instantiated with any type 'T' you desire.
The actual implementation of 'id' takes two parameters. First it takes the
desired type and then it takes the parameter and returns it. Writing 'id
Int' is a partial invocation. It "plugs in" the T and yields a function of
type 'Int -> Int'. Likewise, 'id String' plugs in strings in the position.
Interestingly, Reynolds showed that if the function 'id' is to work for
*any* type T at the same time, it *must* have the above implementation. No
other implementation is valid. This is the concept of parametrization. Even
better, the type T can be a type outside of the type system of the
programming language!

But do note there is no way a function such as 'id' can manipulate the
contents in any way. It is allowed to pass a (generic) data value, but it
is not allowed to scrutinize said data value at all.

The next question is if you can add constraints to the type. In particular,
you want access to the stringer interface in order to grab a string
representation of the values. That is, you want to allow any type T for
which it holds that it is a member of the Stringer interface.

exclaim : Show a => a -> String
exclaim x = show x ++ "!"

The exclaim function is one such function example. It accepts any type 'a'
for which the "Show" interface is implemented. Then it prints the value and
adds an exclamation mark at the end of the string. It works for any type
implementing the "Show interface".

The above code works in Idris, or Haskell with minor modifications, so the
generality is definitely doable.

The price you pay for these types of generalizations tend to be compilation
time or slower execution time. It is one of the places where I tend to
disagree with the Go authors: I think the added compilation time is worth
paying for the added expressive power in the language. I also think you can
make compilation of generics really fast, so the added compilation time is
somewhat manageable (and only paid if you actually invoke a generic
construction).

-- 
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.

Re: [go-nuts] IsZero

2017-07-20 Thread Ian Lance Taylor 
On Thu, Jul 20, 2017 at 1:02 PM, Helton Marques  wrote:
>
> There's some reason to not have the function `IsZero` to time.Duration ?
>
> IMO, I think this can be useful:
>
>
> ```
> type Server struct { timeout time.Duration `yaml:"timeout:"` }
> ...
> if srv.timeout.IsZero() { srv.timeout = defaultServerTimeout }
> ```
>
> Anyone knows if there's some restriction to not have IsZero() bool functions
> to defined types as int64 ?

Where you want to write `d.IsZero()`, you can just write `d == 0`.
I'm not sure adding a `IsZero` method is really worth it.

Ian

-- 
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.

Re: [go-nuts] Anyone using https://github.com/knq/xo?

2017-07-20 Thread Michael Banzon 
I see your point.

I might checkout going bare database/sql on one of my smaller projects to get a 
feel for it - now that I’ve been thinking about it it strikes me that I’ve 
actually never tried database stuff on Go without gorp/gorm etc.

-- 
Michael Banzon
https://michaelbanzon.com/




> Den 20. jul. 2017 kl. 19.22 skrev Nate Finch :
> 
> The main reason is to avoid magic.  My past experience with ORMs has been 
> that they make easy things easier and hard things harder.  Once you start 
> leveraging relational bits, they become incredibly unwieldy to actually use.  
> They also tend to generate wildly suboptimal SQL and rely on a lot of 
> reflection that is just slow.
> 
> On Thursday, July 20, 2017 at 2:56:21 AM UTC-4, mbanzon wrote:
> Just out of curiosity - why switch away from gorm??
> 
> We've just switched from gorp to gorm - with great success. The main reason I 
> could find for going (pun intended) is to have one less dependency.
> 
> --
> Michael Banzon
> https://michaelbanzon.com/ 
> 
> Den 20. jul. 2017 kl. 06.04 skrev Nate Finch  >:
> 
> We're thinking of dropping gorm and switching to plain old database/sql... 
> but I don't really want to generate all that boilerplate myself.  xo looks 
> like it does a reasonable job of generating the boilerplate for you, so I was 
> wondering if anyone had any experience using it in production.  Gotchas, etc.
> 
> -Nate
> 
> -- 
> 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...@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.

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

2017-07-20 Thread 'Eric Johnson' via golang-nuts 
Again, I'm mostly for generics being added to Go, because I've found 
occasion where they would be useful...

On Thursday, July 20, 2017 at 6:40:00 AM UTC-7, M P r a d e s wrote:
>
> Go could have least have parametric functions (ex :
>
> func Foo(value T)T { /.../ }
>
> bar := Foo(3) //types are verified at compile time, no need for 
> reflection or interface {} on any runtime trick.
>
> ).
>

To get at the value of adding generics, knowing what "Foo" is doing is 
important. Presumably, the function operates on "value" in some way.

Can we say that it implements an interface? Then let's suppose the 
existence of an interface "X". I can currently rewrite your "Foo" function 
as:

type X interface {
Clone() X // documentation needed to clarify that the clone is really 
of the derived type implementing X.
DoFoo()
}

func Foo(value X) X {
   result := value.Clone()
   result.DoFoo()
   return result
}

Now supposing I have a struct B, where *B implements "X", and is currently 
in variable "orig".

When calling this, to reflect that the result of Foo is still of type *B, 
the following is required.
   fooClone:=(*B).(Foo(orig))

What I want to be able to write, and have *B as the type of "clone":
   fooClone:=Foo(orig)

What we need the function signature to specify, then, is two pieces of 
information, that the parameter "value" is of the same type as its return, 
and that it implements interface "X". Also, my intuition suggests 
distinguishing generic types from concrete ones syntactically, so add an 
indication that's true. Perhaps try a few (+, ^, %).

A bunch of options that all get at the same idea, using different 
characters and different approaches:
func Foo(value T^->X) T^
func Foo(value T%:X) T%
func Foo(value T+:X) T+
func FooX>(value T^) T^
func FooX>(value T%) T%
func FooX>(value T+) T+

where the "->" could really be anything syntactically appropriate, but what 
it means is "T" implements X. Again, not sure of the right syntax, and not 
sure this is required.

In the "X" interface itself, we have a slightly different problem for the 
"Clone" method. We need someway to indicate "the concrete type of the 
thing". For that, we use the syntax indication of a generic type (^, %, or 
+, above) appended to something. "@" seems like a natural fit. That 
probably needs to look something like this:

Clone() @^

Putting it all together, choosing my favorite representation from above:
type X interface {
Clone() @+
DoFoo()
}

func Foo(value T+:X) T+ {
   result := value.Clone()
   result.DoFoo()
   return result
}

Now, I can write what I wanted to write:

fooClone := Foo(orig)

There's a *completely separate question* as to whether the compiler 
generates code that is effectively of the form:
fooClone := (*B).(Foo(orig))

I'm not sure I care about that. I'm more concerned about the correctness of 
the code.

Eric.
 

>
> But talking about this is kind of useless until Go rids itself of its over 
> reliance on runtime features like reflection. I suspect Go reflection 
> capabilities are why the language stopped evolving significantly at first 
> place. String tags are another symptom of that "disease".
>
> It's possible to write the snippet above with reflection today 
> (reflect.MakeFunc) , it shouldn't be.
>
>
>

-- 
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.

Re: [go-nuts] Anyone using https://github.com/knq/xo?

2017-07-20 Thread Nate Finch 
The main reason is to avoid magic.  My past experience with ORMs has been 
that they make easy things easier and hard things harder.  Once you start 
leveraging relational bits, they become incredibly unwieldy to actually 
use.  They also tend to generate wildly suboptimal SQL and rely on a lot of 
reflection that is just slow.

On Thursday, July 20, 2017 at 2:56:21 AM UTC-4, mbanzon wrote:
>
> Just out of curiosity - why switch away from gorm??
>
> We've just switched from gorp to gorm - with great success. The main 
> reason I could find for going (pun intended) is to have one less dependency.
>
> --
> Michael Banzon
> https://michaelbanzon.com/
>
> Den 20. jul. 2017 kl. 06.04 skrev Nate Finch  >:
>
> We're thinking of dropping gorm and switching to plain old database/sql... 
> but I don't really want to generate all that boilerplate myself.  xo looks 
> like it does a reasonable job of generating the boilerplate for you, so I 
> was wondering if anyone had any experience using it in production. 
>  Gotchas, etc.
>
> -Nate
>
> -- 
> 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...@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.

Re: [go-nuts] Pointer dereference operator precedence

2017-07-20 Thread adrian . price 
That makes sense, thank you! It does make it a little confusing that a 
special case was made for pointers to arrays that violates that rule, but 
it's a pretty rare use case anyway.

Thanks for pointing this out, it was driving me crazy.

On Thursday, July 20, 2017 at 2:47:12 AM UTC-4, Lyuben Blagoev wrote:
>
> I think the behavior is defined with the following statement in the spec:
>
> Primary expressions are the operands for unary and binary expressions. 
>
> x[0] is a primary expression, so it is the operand for the unary 
> expression, thus the expression is avaluated as *(x[0]).
>
> On Thu, Jul 20, 2017 at 4:07 AM, Ian Lance Taylor  > wrote:
>
>> On Wed, Jul 19, 2017 at 4:10 PM,   
>> wrote:
>> >
>> > The EBNF specifies the syntax, not the behavior. EBNF does not indicate 
>> the
>> > order of evaluation of source code, only the order of characters in the
>> > source code.
>>
>> Fair point.  In this case it is also intended to indicate the
>> precedence.  In fact, in every case I know of, it indicates the
>> precedence.
>>
>> Ian
>>
>> > On Wednesday, July 19, 2017 at 6:59:29 PM UTC-4, Ian Lance Taylor wrote:
>> >>
>> >> On Wed, Jul 19, 2017 at 3:28 PM,   wrote:
>> >> >
>> >> > A question on Stack Overflow led me to carefully examine the spec 
>> and I
>> >> > feel like there may be some detail that's missing - the behavior is 
>> easy
>> >> > enough to work with, but it's effectively undefined according to the
>> >> > language spec. Specifically, with a variable x of type *[]string for
>> >> > example, *x[0] will not work because it is evaluated as *(x[0]), not 
>> as
>> >> > (*x)[0]. This is unexpected based on the spec because the only
>> >> > specifications that could apply are the general order of evaluation, 
>> which
>> >> > is left to right (not the case here), and operator precedence which 
>> states
>> >> > that pointer dereference is a unary operator and unary operators have
>> >> > highest precedence (again clearly not what's happening).
>> >> >
>> >> > The closest it comes to explaining this behavior is in the section on
>> >> > address operators, which implies that the address operator & applies 
>> to the
>> >> > entire slice expression next to it (or struct field selector, etc). 
>> This
>> >> > leaves one to assume the same implication applies to the pointer 
>> dereference
>> >> > operator as well.
>> >> >
>> >> > Is there something covering this that I glossed over reading the 
>> spec?
>> >> > If it's not just something I missed, is this worth clarifying in the 
>> spec,
>> >> > without changing the behavior (purely a documentation change)?
>> >>
>> >> This is expressed in the EBNF grammar in the language spec.  x[0] is a
>> >> PrimaryExpr.  *x[0] is a unary_op applied to a PrimaryExpr.
>> >>
>> >> Ian
>> >
>> > --
>> > 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...@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...@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.

Re: [go-nuts] Re: Code Review - Applying functions on custom types

2017-07-20 Thread silviucapota 
Hi Sofiane,

Answering the "what type" question is pretty much unavoidable. 
You can embed that forking logic inside the "on the fly" function, like in 
Roger's example (using a switch v := v.(type) construct) or you can use 
reflect.

Alternatively, you can group your transformation functions into 
functionality buckets, using maps: map[string]TFunc (where TFunc is 
func(Valuer) Valuer like you wanted).
Each of your types (CSVString or CSVFloat, etc) would be "tied" to such a 
map, returned by a new method in the Valuer interface: TFuncs() 
map[string]TFunc
Quick example here:  https://play.golang.org/p/ZnqJVw0Wzq
I just added some extra stuff to your code. I didn't bother trying to 
understand if you wanted your rows mutated for each operation, or copied, 
or such. That's your decision.

For chaining transformers, please note that I changed your r := Row { ... } 
 to var r Transformer = { ... }

Keep in mind that a lot of functional paradigms do not apply cleanly to Go. 
For readability purposes, a simple for loop works wonders and it's 
oftentimes more readable :)

cheers,
silviu




On Thursday, 20 July 2017 07:58:09 UTC-4, rog wrote:
>
> I'm not convinced that holding all your values in a uniform way
> is going to be that helpful for you. You might be better using reflection
> to map the columns into a struct type (there's probably a package
> out there already that can do that).
>
> However, to answer without questioning the whole premise:
>
> You can't pass a function on a specific type to the more generally
> typed func(Valuer)Valuer because the value in the column might not
> be of the specific type - what should happen if the column is a string
> and you pass func(CSVFloat)CSVFloat to Apply?
>
> Here's your code made to work, with some arguably redundant stuff
> removed. The Transformer type seemed unnecessary, as Apply
> and RemoveColumn both work with the row in place. The Type field
> in the Column struct seemed unnecessary, as the type is implied by
> the value in the column. Also, the whole notion of Type seemed
> a bit redundant as CSV files have no notion of type, and it seems like
> you want to support custom types. The CSV prefix on the type names
> seemed unnecessary, as this would probably be in a package with
> some kind of csv-related name.
>
> https://play.golang.org/p/9mSfG1m4VZ
>
>   cheers,
> rog.
>
> On 20 July 2017 at 08:05, Sofiane Cherchalli  > wrote:
>
>> Hi Silviu,
>>
>> Thanks for the reply.
>>
>> Basically I want to kinda functional map on my custom types by applying 
>> functions on base value or struct values.
>>
>> What if I want to for instance:
>>
>> - Multiply the float64 value inside CSVFloat by 2 ?
>> - or Replace a custom type value with another one from the same type?
>>
>> Thanks
>>
>>
>> On Thursday, July 20, 2017 at 5:09:40 AM UTC+2, Silviu Capota Mera wrote:
>>>
>>> Before: myfn := func(v CSVFloat) CSVFloat { return v }
>>>
>>> After: myfn := func(v Valuer) Valuer { return v }
>>>
>>> On Wednesday, 19 July 2017 16:48:07 UTC-4, Sofiane Cherchalli wrote:

 Hi!

 I'm a noob in Go and I need some guidance/help on this: 
 https://play.golang.org/p/0TGzKiYQZn

 Basically I'm implementing a CSV parser, and applying transformations 
 on column value.

 In last part of the code I'm trying to apply a function on CSVFloat 
 type which satisfies Valuer interface, but I got a compiler error.

 In Scala language, this could be done by using map function, but how to 
 do it in Golang?

 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...@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.

[go-nuts] Re: How do you test a server?

2017-07-20 Thread st ov 
Thats a great resource, thank you!

Also does the htttptest.Server mock out a server so that you can test 
clients?
What if I want to test my own server?



On Wednesday, July 19, 2017 at 10:07:44 AM UTC-7, Jérôme LAFORGE wrote:
>
> One of my favorite resource can be found here about testing server
> https://github.com/bradfitz/talk-yapc-asia-2015/blob/master/talk.md#testing

-- 
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: "interface{} says nothing", lets consider it destroys information

2017-07-20 Thread mhhcbon 
In func Foo(value T)T { /.../ }

It makes sense to anchor the definition of T to the func name.

I feel like it is not needed, and i wonder about multiple T parameters.

Where the question here is about

func Foo(x , y ) (, ){}
Or
func Foo(x t, y u) (t, u){}


At least, it is possible to say your version has more impact on the overall 
syntax than my initial proposal,
because using your version there will be new things like

bar := Foo(3)

In my proposal, because 3 is an int,  is solved.


another very questionable thing, 
if you have  (basic type), you can return only a (string), or 
destruct it into another type (strconv.Atoi).
that happens because string does not match any interface, its basic.
So f() seems totally useless and redundant to f(string).

  is really interesting with structs and interfaces,
because struct can have as many facets as there is interface it satisfies.
- its open for the caller, you can inject and receive any type that 
satisfies the contract
- closed to the declarer, it must become a meaningful type before you 
actually interact with it




Aside of this, i have lots of troubles to write the clear distinction 
between interface{} and interface.
I d really like we had another keyword like *contract* to define an 
interface.
or empty{} rather than interface{}.

Anything that get rides of this naming problem.

On Thursday, July 20, 2017 at 3:40:00 PM UTC+2, M P r a d e s wrote:
>
> Go could have least have parametric functions (ex :
>
> func Foo(value T)T { /.../ }
>
> bar := Foo(3) //types are verified at compile time, no need for 
> reflection or interface {} on any runtime trick.
>
> ).
>
> But talking about this is kind of useless until Go rids itself of its over 
> reliance on runtime features like reflection. I suspect Go reflection 
> capabilities are why the language stopped evolving significantly at first 
> place. String tags are another symptom of that "disease".
>
> It's possible to write the snippet above with reflection today 
> (reflect.MakeFunc) , it shouldn't be.
>
>
>

-- 
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: "interface{} says nothing", lets consider it destroys information

2017-07-20 Thread prades . marq 
Go could have least have parametric functions (ex :

func Foo(value T)T { /.../ }

bar := Foo(3) //types are verified at compile time, no need for 
reflection or interface {} on any runtime trick.

).

But talking about this is kind of useless until Go rids itself of its over 
reliance on runtime features like reflection. I suspect Go reflection 
capabilities are why the language stopped evolving significantly at first 
place. String tags are another symptom of that "disease".

It's possible to write the snippet above with reflection today 
(reflect.MakeFunc) , it shouldn't be.


-- 
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.

Re: [go-nuts] go get awkwardness with packages outside of GOPATH

2017-07-20 Thread Wojciech S. Czarnecki 
On Thu, 20 Jul 2017 03:08:58 -0700 (PDT)
"'Florian Uekermann' via golang-nuts"  wrote:

> The go tool does not provide a way to update 
> dependencies of packages that are not go get-able.

Yes it is. Go tooling is based on and has a convention to follow. Hence there
is no support for "place pieces at will" scenarios.

Once you broke away from go convention you're pretty much on your own.
Eg. you may consider a makefile with something like "updatedeps" target
or you may vendor your dependencies at some mirror place. Note, that go
tooling does *not* allow symlinks!

I'd suggest keeping to go tool expectations though. Third party pm-s and
home baked scripts will not survive enough long to be on pair with evolving
genuine tool.

> 
> Thanks,
> Florian

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.

Re: [go-nuts] Re: Code Review - Applying functions on custom types

2017-07-20 Thread roger peppe 
I'm not convinced that holding all your values in a uniform way
is going to be that helpful for you. You might be better using reflection
to map the columns into a struct type (there's probably a package
out there already that can do that).

However, to answer without questioning the whole premise:

You can't pass a function on a specific type to the more generally
typed func(Valuer)Valuer because the value in the column might not
be of the specific type - what should happen if the column is a string
and you pass func(CSVFloat)CSVFloat to Apply?

Here's your code made to work, with some arguably redundant stuff
removed. The Transformer type seemed unnecessary, as Apply
and RemoveColumn both work with the row in place. The Type field
in the Column struct seemed unnecessary, as the type is implied by
the value in the column. Also, the whole notion of Type seemed
a bit redundant as CSV files have no notion of type, and it seems like
you want to support custom types. The CSV prefix on the type names
seemed unnecessary, as this would probably be in a package with
some kind of csv-related name.

https://play.golang.org/p/9mSfG1m4VZ

  cheers,
rog.

On 20 July 2017 at 08:05, Sofiane Cherchalli  wrote:

> Hi Silviu,
>
> Thanks for the reply.
>
> Basically I want to kinda functional map on my custom types by applying
> functions on base value or struct values.
>
> What if I want to for instance:
>
> - Multiply the float64 value inside CSVFloat by 2 ?
> - or Replace a custom type value with another one from the same type?
>
> Thanks
>
>
> On Thursday, July 20, 2017 at 5:09:40 AM UTC+2, Silviu Capota Mera wrote:
>>
>> Before: myfn := func(v CSVFloat) CSVFloat { return v }
>>
>> After: myfn := func(v Valuer) Valuer { return v }
>>
>> On Wednesday, 19 July 2017 16:48:07 UTC-4, Sofiane Cherchalli wrote:
>>>
>>> Hi!
>>>
>>> I'm a noob in Go and I need some guidance/help on this:
>>> https://play.golang.org/p/0TGzKiYQZn
>>>
>>> Basically I'm implementing a CSV parser, and applying transformations on
>>> column value.
>>>
>>> In last part of the code I'm trying to apply a function on CSVFloat type
>>> which satisfies Valuer interface, but I got a compiler error.
>>>
>>> In Scala language, this could be done by using map function, but how to
>>> do it in Golang?
>>>
>>> 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.

Re: [go-nuts] go get awkwardness with packages outside of GOPATH

2017-07-20 Thread 'Florian Uekermann' via golang-nuts 
See my previous answer to ohir for a less convoluted and less specific 
problem statement. My problem does not seem to be related to being inside 
or outside a GOPATH.
 

> Dependencies are derived from import paths. Import paths are not complete 
> paths. They are transformed to complete paths by searching every part in 
> $GOPATH as in filepath.Join(part, "src", importPath).
>
> How do you propose to update dependencies outside a $GOPATH? How should be 
> the import paths transformed to complete paths?
>

Thanks for your answer.
The import path transformation should work same way it works right now. "go 
get" works perfectly fine outside a GOPATH until the install step (which 
you can prevent using -d) or if you use -u. I believe it just uses the 
first "part" of GOPATH (or $HOME/go as of 1.8 if GOPATH is not defined). I 
fail to see the problem. Could you elaborate if I misunderstood you?

Best regards,
Florian

-- 
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.

Re: [go-nuts] go get awkwardness with packages outside of GOPATH

2017-07-20 Thread 'Florian Uekermann' via golang-nuts 
Thanks for the suggestions. I may not have explained the setup well enough. 
I don't think your suggestions work if you just have your code in a folder 
without any additional structure (no src directory).
But your first suggestion prompted my to play around with having the 
package in a GOPATH and I realized that my problem is much less specific 
than I thought, since go get -u also does not work with local packages (no 
vc or no git remote origin). So I guess I jumped to a much too specific 
conclusion and problem statement.

I should restate the issue as: The go tool does not provide a way to update 
dependencies of packages that are not go get-able. Inside or outside GOPATH 
has nothing to do with it.

Thanks,
Florian

-- 
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.