On Saturday, October 20, 2018 at 12:17:16 AM UTC-4, Raffaele Sena wrote:
>
> Inspired by ESR pytogo (and tired of writing python code), I went the
> complete opposite way and came up with pygor:
>
Bravo.
I am amused by the name - puts me in mind of Discworld Igors. And if my
sadly departed
Andy Balholm :
> It seems to me that what you are proposing with “implements” is not really a
> replacement for contracts. It would do something that contracts don’t (unify
> operators and methods), and it wouldn’t do nearly all of what contracts do
> (clearly define what is expected of type
Ian Denhardt :
> Quoting Eric S. Raymond (2018-10-19 16:15:25)
> > Ian Denhardt :
> > > What would code making use of a `Sortable` type look like? If you can't
> > > actually use "implements <" to overload `<`, it's not clear to me what
> > > it would actually do?
> >
> > Be available to a Sort
Inspired by ESR pytogo (and tired of writing python code), I went the
complete opposite way and came up with pygor:
https://github.com/raff/pygor
pygor is written in Go, using the Python parser and AST from
https://github.com/go-python/gpython (so right now it only targets Python
3.4). The
Tamas, that's checking if the offset at a particular instant was the same as
the local zone - what OP cares about is that the caller is not using literally
"time.Local" in their code.
I recommend performing source analysis for this - it's a lot easier on you than
runtime checks.
--
You
Hi all,
See some related discussion here regarding dots in import paths and modules:
https://github.com/golang/go/issues/27503
including this comment from bcmills:
"Dotless paths in general are reserved for the standard library; go get
has (to my knowledge) never worked with them, but go
Actually, now that I think about it, this restriction was relaxed. So
the dot in the first part of the path is not a requirement.
It appears however that go mod edit has partially regressed in this respect.
Please can you raise an issue? That way we can have the behaviour
confirmed one way or
I see though that "go mode edit" really wants there to be a dot in the
first part of the import path.
Where can I read about that requirement?
On Fri, Oct 19, 2018 at 6:30 PM Mark Volkmann
wrote:
> Thank you so much! I actually got it to work without having a dot in the
> first part of the
Thank you so much! I actually got it to work without having a dot in the
first part of the import path.
It seems the only thing I was missing was this line in mod.go for the demo
code:
require foo/bar v0.0.0
I just had the replace directive line without a corresponding require
directive.
On Fri,
Hi Mark,
When importing a module package, the first element in the path must
contain a ".". Hence "foo" is invalid. Here is a working example:
$ cd $HOME
$ mkdir bar
$ cd bar
$ go mod init example.com/bar
go: creating new go.mod: module example.com/bar
$ cat
On Sat, Oct 20, 2018, 11:34 AM Mark Volkmann
wrote:
>
> On Oct 19, 2018, at 4:48 PM, Justin Israel wrote:
>
>
>
> On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
> wrote:
>
>> I have a simple demo application that wants to use a package that is on
>> my local file system.
>> The code for the
> On Oct 19, 2018, at 4:48 PM, Justin Israel wrote:
>
>
>
>> On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
>> wrote:
>> I have a simple demo application that wants to use a package that is on my
>> local file system.
>> The code for the package is in /Users/Mark/foo/bar.
>> This directory
On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
wrote:
> I have a simple demo application that wants to use a package that is on my
> local file system.
> The code for the package is in /Users/Mark/foo/bar.
> This directory contains the file bar.go which contains:
>
> package bar
> import "fmt"
>
As I said, I don't really understand why we disagree here - or what we are
even disagreeing about. So let me make my claim as precise as possible, in
the hope that it at least helps me understand which particular part you are
disagreeing with. I claim:
a) w.l.o.g. we can ignore operators
It seems to me that what you are proposing with “implements” is not really a
replacement for contracts. It would do something that contracts don’t (unify
operators and methods), and it wouldn’t do nearly all of what contracts do
(clearly define what is expected of type parameters across a wide
On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote:
>
> Quoting Burak Serdar (2018-10-19 14:09:46)
>
> > It is useful in a linked list. You can instantiate a linked list
> > template in a package, and use that concrete type in another package
> > without access to the internals of the linked
Quoting Eric S. Raymond (2018-10-19 16:15:25)
> Ian Denhardt :
> > What would code making use of a `Sortable` type look like? If you can't
> > actually use "implements <" to overload `<`, it's not clear to me what
> > it would actually do?
>
> Be available to a Sort function. That is, the
Ian Denhardt :
> Quoting Eric S. Raymond (2018-10-19 16:03:02)
>
> > Both classes want to be selected by a field "name". It's annoying that
> > I can't declare an interface that says "has a field 'name'" and instead
> > have to declare a getter function with no other point besides sliding
> >
I have a simple demo application that wants to use a package that is on my
local file system.
The code for the package is in /Users/Mark/foo/bar.
This directory contains the file bar.go which contains:
package bar
import "fmt"
func Hello() {
fmt.Println("Hello from bar!")
}
It also contains the
Quoting Burak Serdar (2018-10-19 15:13:20)
> Without operator overloading:
>
> type X interface {
>implements <
> }
>
> means that you want a primitive numeric type or a string. So:
This is not quite quite correct; in Eric's proposal, it is possible to
define (for example):
```
// A
Ian Lance Taylor :
> > Both classes want to be selected by a field "name". It's annoying that
> > I can't declare an interface that says "has a field 'name'" and instead
> > have to declare a getter function with no other point besides sliding
> > around that restriction.
>
> I think you are
alan.f...@gmail.com :
> I also don't think that Eric was being disrespectful to Ian LT and Robert.
> He simply has a profound dislike for the draft generics design and believes
> in expressing himself forcibly and at times, comically :)
True dat!
Your grasp of this nuance is appreciated.
--
Ian Denhardt :
> Second, I agree with Tristan that Eric's sibling comment is a bit sharp;
> let's be careful to keep this civil, as it's clear that some of us are
> feeling a bit tense.
I was serious when I said I meant no insult, and apologize to any who
felt insulted.
> Ultimately however I
Ian D,
The introduction is certainly not intended to be insulting to those who
have put serious thought into the problem. If it were, then I'd be
insulting myself as I've put serious thought into at least two other
proposals which are nothing like the current one!
It's simply a realization
Ian Denhardt :
> What would code making use of a `Sortable` type look like? If you can't
> actually use "implements <" to overload `<`, it's not clear to me what
> it would actually do?
Be available to a Sort function. That is, the requirement "Have a Less()"
would be replaced by "Have an
On Fri, Oct 19, 2018 at 1:03 PM, Eric S. Raymond wrote:
> Burak Serdar :
>> One other difference between the two is the ability of the "like"
>> syntax to use a struct as well as an interface for templates, so you
>> can require concrete implementations to have certain fields, instead
>> of
I think we need to focus this thread on comments just about alanfo's
suggestion. Let's not start debating how to debate. And, of course,
let's remember the code of conduct: https://golang.org/conduct .
Thanks.
Ian
--
You received this message because you are subscribed to the Google Groups
Burak Serdar :
> One other difference between the two is the ability of the "like"
> syntax to use a struct as well as an interface for templates, so you
> can require concrete implementations to have certain fields, instead
> of getter/setters.
I'm puzzled that this is not already possible in
Quoting Eric Raymond (2018-10-19 14:43:51)
>Therefore, as the author of the "implements" proposal, I am declaring
>neutrality on whether an "implements" clause should declare an overload
>at all!
>That is, there is a possible future in which "implements <" on type T�
>does
First, I find the introduction to this condescending; it amounts to "the
Go developers know what they're doing, stop questioning them plebians!"
It is phrased more politely, but the content is basically there. This
is:
1. Insulting to those of us who also have put serious thought
into the
Tristan Colgate :
> It is not at all obvious that you have sufficient experience of writing Go
> for anyone to take your, rather disrespectful, comments seriously.
Nor is it obvious that an elegant solution can be found by anyone who has been
too close to the problem for too long and gotten stuck
On Fri, Oct 19, 2018 at 1:26 PM Eric S. Raymond wrote:
>
> Burak Serdar :
> > So the question is: do we really need to declare exactly what the
> > implementation of a generic needs in the contract, or is it sufficient
> > to say "use this with values that are like type X"?
>
> I think the
Burak Serdar :
> So the question is: do we really need to declare exactly what the
> implementation of a generic needs in the contract, or is it sufficient
> to say "use this with values that are like type X"?
I think the additional explicitness of "implements" is valuable. And
my syntax is
On Fri, Oct 19, 2018 at 11:48 AM Eric S. Raymond wrote:
>
> Burak Serdar :
> > Where can I read about this "implements"? Link?
>
> https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM
>
> After subsequent discussion I would only add these points:
>
> * The "implements" construct is not
Quoting Burak Serdar (2018-10-19 14:09:46)
> It is useful in a linked list. You can instantiate a linked list
> template in a package, and use that concrete type in another package
> without access to the internals of the linked list.
Can you provide an example of what some code using this would
On Fri, Oct 19, 2018 at 12:36 PM Ian Lance Taylor wrote:
>
> On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote:
> > On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote:
> >>
> >> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote:
> >> >
> >> > Instead of specifying the minimal set of
On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer wrote:
>
> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote:
>>
>> The question is: is anybody actually doing this? Is anybody seriously
>> thinking about it?
>
> Unhelpfully, I imagine it unlikely that anyone distributing
It is not at all obvious that you have sufficient experience of writing Go
for anyone to take your, rather disrespectful, comments seriously.
Ian has been working on finding a workable model for generic programming
in Go for at least 5 years. To many of us, contracts look like a pragmatic
I think Ian Denhardt is right to argue that fear of operator overloading is
driving people in the generics debate to complicated, ugly workarounds that
should not be.
I myself do not actually want overloading as a surface feature of the
language. In my original "implements" proposal, I
On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote:
> On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote:
>>
>> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote:
>> >
>> > Instead of specifying the minimal set of operations a type should
>> > satisfy, why not describe what the type
On Fri, Oct 19, 2018 at 12:01 PM Ian Denhardt wrote:
>
> Quoting Burak Serdar (2018-10-19 12:34:44)
> > Re: Ian Denhardt's proposal:
> >
> > I agree that it handles all the cases in the official proposal,
> > but I think the syntax is too verbose and reminds me of
> > Java. For instance, the
Quoting Burak Serdar (2018-10-19 12:46:19)
> Where can I read about this "implements"? Link?
This is the thread:
https://groups.google.com/forum/#!search/go-nuts/golang-nuts/pR5pmql5olM/RPDuL2BsCAAJ
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Quoting Burak Serdar (2018-10-19 12:34:44)
> Re: Ian Denhardt's proposal:
>
> I agree that it handles all the cases in the official proposal,
> but I think the syntax is too verbose and reminds me of
> Java. For instance, the "sorting" example can be written using
> the "like" keyword as:
>
>
On Friday, October 19, 2018 at 1:48:36 PM UTC-4, alanfo wrote:
>
> In the light of all the feedback there's been, I've put together a
> proposal which sticks closely to the original design and only changes what
> most people consider needs to be changed in some way. Some recent ideas
> which
Burak Serdar :
> Where can I read about this "implements"? Link?
https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM
After subsequent discussion I would only add these points:
* The "implements" construct is not a full generic-type system in
itself, nor is it meant to be. It's
My head has been spinning lately after reading the various generic
counter-proposals and suddenly the original draft design seems a lot more
attractive than it did :)
In the light of all the feedback there's been, I've put together a proposal
which sticks closely to the original design and
On Fri, Oct 19, 2018 at 10:38 AM Eric S. Raymond wrote:
>
> Ian Denhardt :
> > I feel like Burak's proposal is falling into the same trap as many others:
> > there is a common feeling that operator overloading is a Pandora's box, so
> > folks are trying to work around it by solving the problem
Ian Denhardt :
> I feel like Burak's proposal is falling into the same trap as many others:
> there is a common feeling that operator overloading is a Pandora's box, so
> folks are trying to work around it by solving the problem without providing
> operator overloading. But *the problem itself* is
On Fri, Oct 19, 2018 at 7:13 AM Robert Engels wrote:
>
> I don’t think it matters, since when writing the generic code using methods
> the author has strict control over the precedence.
>
> Also, for equality testing, the signature would be bool Equals(interface{})
> with required casting.
Andy Balholm :
> I don’t think that generic functions should have access to private
> fields of their type parameters, regardless of what package they are
> in.
Agreed. Turns me off this proposal somewhat.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the
Beoran :
> I think the idea we should focus on here is "The type is the contract".
> Instead of specifying a contract though operations, just use concrete
> types, including primitive types to specify the desired qualities of the
> generic type.
This is, of course, similar to my "implements"
On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote:
>
> The question is: is anybody actually doing this? Is anybody seriously
> thinking about it?
>
> Ian
>
Unhelpfully, I imagine it unlikely that anyone distributing binary go
packages reads golang-dev or golang-nuts.
I don’t think it matters, since when writing the generic code using methods the
author has strict control over the precedence.
Also, for equality testing, the signature would be bool Equals(interface{})
with required casting. Without looking for flames, this is how Java does it and
it’s never
On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote:
>
> I guess I don’t understand the problem with using “method names” e.g.
> Less() in generic code - yes it is a little more verbose - but it avoids
> the traditional problems with operator overloading leading to obtuse code.
>
>
On Fri, 19 Oct 2018 at 12:04, roger peppe wrote:
> The algorithm to do it is quite straightforward:
> https://play.golang.org/p/subnLkSSxdI
>
On reflection, that ParamType hack won't work correctly with
types.Identical. This should work better:
https://play.golang.org/p/iswgf7mr8ht
>
--
You
On Thu, 18 Oct 2018 at 13:41, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote:
>
>> For generics, that analysis is trivial - there is no need to do any
>> control flow analysis to determine the set of possible generic type
>> parameters to a type or function (with the
Thanks!
Not using the packages was the issue.
On Friday, October 19, 2018 at 10:10:25 AM UTC+2, Elias Naur wrote:
>
> You're not using the imports. To avoid generating for the entire Android
> API, the reverse generator only generates bindings referenced by your code.
> For examples, see
You're not using the imports. To avoid generating for the entire Android
API, the reverse generator only generates bindings referenced by your code.
For examples, see golang.org/x/mobile/bind/testdata/testpkg/javapkg. This
works for me:
$ gomobile bind
Hi,
I just tried but it doesn't work:
$ ls
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
$ gomobile bind -v -bootclasspath
I see. For Android API, you'll need to specify the bootstrap classpath by
setting the gomobile -bootclasspath flag to point to the android.jar from
the Android SDK that matches your platform version. For example:
$ gomobile bind -bootclasspath /platforms/android-27/android.jar
If you need
I'd say it's a useful feature, but not in it 's current form. I rather than
dropping the featture I'd like to see it enhanced so so it works as well as
a pascal .unit file does as a binary package for a high level language.
This also points to a solution as well, have a .gobin file that is an
Simple example:
package test
import (
"Java/android/content"
"Java/android/content/pm"
)
func Test() string {
return "Hello world"
}
returns
$ gomobile bind -v git.xxx.com/test
type-checking package "git.xxx.com/test" failed
2018. október 19., péntek 8:26:22 UTC+2 időpontban Tamás Gulácsi a
következőt írta:
>
> Just check whether a specific time is the same with the specified location
> and with the Local location:
>
> if time.Date(2006,time.Month(1), 1, 0,0,0,0,
>
Just check whether a specific time is the same with the specified location
and with the Local location:
if time.Date(2006,time.Month(1), 1, 0,0,0,0,
time.Local).Equal(time.Date(2006,time.Month(1),1,0,0,0,0,
offset.Location()) { return error }
2018. október 19., péntek 8:08:05 UTC+2
Sorry, I did not mean to hijack the discussion.
To summarize our answer on Russ's question - in a current form Go's binary
packages are not useful for our team.
Thanks,
Andrey
On Thursday, October 18, 2018 at 2:15:57 PM UTC-6, Ian Lance Taylor wrote:
>
> On Thu, Oct 18, 2018 at 1:10 PM,
Hey folks,
I'm trying to ensure that the user must pass a specific location (anything
but time.Local) into a function.
I'd like to add a check like this:
// ensure we didn't pass in an offset the default time.Local
if offset.Location() == time.Local {
return nil, errors.New("offset use a
66 matches
Mail list logo
