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 f
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 par
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 o
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 fun
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 receiv
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 the
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 impor
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, O
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 packag
> 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 con
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"
> fun
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 (includin
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 r
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 list.
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 requirem
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
> > arou
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 f
Quoting Ian Denhardt (2018-10-19 16:29:07)
>
> Quoting Burak Serdar (2018-10-19 15:13:20)
> > Without operator overloading:
> >
Realized I missed this right after hitting send. Yes, without operator
overloading you're restricted to built-in types that already support the
operator. The original mot
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 Version
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 talki
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 agr
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 I'v
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 impleme
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 getter
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 int
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 not�
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 probl
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 additio
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 light
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
I always assumed that there is no "private" in Go - it is either public or
package level. So generic's being able to access same package level
accessible things seems to be logical.
Andrey
On Thursday, October 18, 2018 at 10:21:15 AM UTC-6, Andy Balholm wrote:
>
> I don’t think that generic fun
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 bin
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
solutio
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 accept
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 sh
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 "sort
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" grou
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:
>
> Temp
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 s
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 meant
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 only
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 wit
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. Witho
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 I
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" p
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 r
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 exce
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 golan
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 golang.org/x/mobile/bind/testdata/testpkg/
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
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/an
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 acce
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
a
63 matches
Mail list logo
