On Thu, Oct 18, 2018 at 9:37 AM robert engels wrote:
>
> That is true, it would be done that way, so not an issue. Sorry for the
> tangent.
>
> I still don’t understand when ‘like T’ when T is a concrete type. It seems
> daunting, unless you use the containment as outlined previously - but a X
I guess you could do it that way, but still, then you need to document every
private field as if it were public, leading to very brittle code… imagine the
compiler error - struct X does not have field xyz… ? Then I need to go to the
source of Y and look at how xyz is documented (hopefully), and
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 should look like:
> >
> > func f(in like T)
>
> I don't see how
On Thu, Oct 18, 2018 at 8:01 AM Robert Engels wrote:
>
> Try it with a user defined type. The only point of generic is to write a
> method once. So when I call it with another type it works correctly. So if
> you write the generic method with a like Foo but I want to call it with a Bar
> what
On Thu, Oct 18, 2018 at 8:53 AM Robert Engels wrote:
>
>
>
> > On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote:
> >
> > If X is a struct type, any type implementing all the methods of X and
> >containing all the fields of X can be substituted
>
> The above is the problem. This almost
On Thu, Oct 18, 2018 at 8:53 AM Robert Engels wrote:
>
>
>
> > On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote:
> >
> > If X is a struct type, any type implementing all the methods of X and
> >containing all the fields of X can be substituted
>
> The above is the problem. This almost
> On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote:
>
> If X is a struct type, any type implementing all the methods of X and
>containing all the fields of X can be substituted
The above is the problem. This almost certainly requires dynamic access to
fields, essentially making all
That is true, it would be done that way, so not an issue. Sorry for the tangent.
I still don’t understand when ‘like T’ when T is a concrete type. It seems
daunting, unless you use the containment as outlined previously - but a X
containing T, is far different than X being a T, and I am not
I don’t think that generic functions should have access to private fields of
their type parameters, regardless of what package they are in.
Andy
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Right, that is a big limitation - that means that internal details must be made
public, or everything in the same package - which is even worse, because then
you have other private details accessible. Breaks encapsulation.
Field access just seems unworkable to me. To much to understand (and
Try it with a user defined type. The only point of generic is to write a method
once. So when I call it with another type it works correctly. So if you write
the generic method with a like Foo but I want to call it with a Bar what
methods does Bar need to implement ? All of the methods of Foo -
On Thu, Oct 18, 2018 at 10:03 AM robert engels wrote:
>
> Right, that is a big limitation - that means that internal details must be
> made public, or everything in the same package - which is even worse, because
> then you have other private details accessible. Breaks encapsulation.
That is
On Wed, 17 Oct 2018 at 17:30, Kyle Butz wrote:
> It looks like transport() is returning a RoundTripper by value. Does that
> mean that "return DefaultTransport" returns a new copy of DefaultTransport,
> or just a copy of a pointer to the global DefaultTransport defined in
> transport.go?
>
You
The go command supports "binary-only packages", in which
the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg
but the corresponding source code is only a stub with relevant
imports (for linking), a special comment marking it as a binary-only
package, and perhaps documentation for exported
On Thu, Oct 18, 2018 at 10:13 AM robert engels wrote:
>
> I guess you could do it that way, but still, then you need to document every
> private field as if it were public, leading to very brittle code… imagine the
> compiler error - struct X does not have field xyz… ? Then I need to go to the
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 should look like:
>
> func f(in like T)
I don't see how this approach can handle multiple types that need to
work together in some
The purpose of a standard, in my opinion, is to allow multiple
implementations to be compatible. This seems counter to the open-source
model, where there is a reference implementation completely in the open
that encourages community participation and improvement.
JavaScript needs a standard -
References
- RFC https://tools.ietf.org/html/draft-rescorla-tls-esni-00
- https://blog.cloudflare.com/esni/
- https://www.cloudflare.com/ssl/encrypted-sni/
-
https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
--
You received this message
> JavaScript needs a standard - there are many implementations and browsers.
> For the moment, there is only one Go, and I like that.
one go, but two reference implementation. any other implementation is
expected to conscribe to the spec.
--
You received this message because you are subscribed
Hi Ian,
Thanks for the clarification!
This means source-code is the only way to share the work. When it companies
to sharing/selling their work on top of which others can build their
app/solution, this won't work. Doesn't this seem like a big restriction?
Particularly, computer industry being
On Thu, Oct 18, 2018 at 1:22 PM robert engels wrote:
>
> Can you explain this a bit more, I must be missing something. Using the
> example:
>
> func F(a,b type T like(int,X)) {
> if a ...
> }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???
You missed the part
Quoting robert engels (2018-10-18 15:22:36)
> Can you explain this a bit more, I must be missing something. Using the
> example:
>
> func F(a,b type T like(int,X)) {
> if a ...
> }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???
>
> Which is why I proposed that
Hello,
I have to agree that binary packages In the current form are not very
useful, at least to us. We have played with an idea of having sqlite (C + a
Go wrapper on top) wrapped up into a binary package, so we can continue to
build multiple platforms from a single build machine. As result of
On Thu, Oct 18, 2018 at 2:02 PM Ian Denhardt wrote:
>
> Quoting robert engels (2018-10-18 15:22:36)
> > Can you explain this a bit more, I must be missing something. Using the
> > example:
> >
> > func F(a,b type T like(int,X)) {
> > if a > ...
> > }
> > }
> >
> > How do you pass a
Hi All,
I have a quick question. I hope I am not off topic.
If this happens, by design, Go will not allow, say, a middleware company to
provide binary only distribution?
Regards
dharani
On Thu, Oct 18, 2018 at 1:15 PM Ian Lance Taylor wrote:
> On Thu, Oct 18, 2018 at 1:10 PM, Andrey
Does
gomobile bind
work? If not, what does it say?
- elias
--
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
On Thu, Oct 18, 2018 at 2:20 PM, Tharaneedharan Vilwanathan
wrote:
>
> If this happens, by design, Go will not allow, say, a middleware company to
> provide binary only distribution?
Yes. There would be no way to for a company to provide a binary-only
package to its users. They would have to
On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan
wrote:
>
> This means source-code is the only way to share the work. When it companies
> to sharing/selling their work on top of which others can build their
> app/solution, this won't work. Doesn't this seem like a big restriction?
>
In the past (C/C++ days) we used a lot of third-party binary-only packages
like SmartHeap for memory management and LeadTools for imaging. (I like to
think of that as the "Programmer's Paradise" era.) I haven't used
binary-only packages in many years, but I do wonder how a company like
Hi Ian,
Good question. I don't have an answer.
But this raises some questions:
Should Go be anticipating many such possibilities today and tomorrow? Or
shut them off?
With this limitation, doesn't it look like Go is best suited for building
end products or service but one cannot build on top
Let's get serious about this. I started a GitHub repository to work on this
proposal. https://github.com/beoran/go-like-generics-proposal/
You are all cordially invited to help out fleshing out this proposal.
--
You received this message because you are subscribed to the Google Groups
Can you explain this a bit more, I must be missing something. Using the example:
func F(a,b type T like(int,X)) {
if a On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote:
>
> I don't think this is fear, but rather KISS. The reason many people dislike
> contracts from the official
Sorry, it is confusing… because then someone chimes in and says ‘no’ to
operator overloading which would make that impossible, which makes the example
impossible for arbitrary X.
I guess I don’t understand the problem with using “method names” e.g. Less() in
generic code - yes it is a little
I don't think this is fear, but rather KISS. The reason many people dislike
contracts from the official proposal is that they are complex and don't have a
very Go-like syntax.
I like this like syntax because I feel it is more Go-like, but also because it
solves the operator problem rather
That would also be a weakness of most of the other proposals, including my own
to add operators to interfaces. Contracts are more powerful, at the expense of
extra complexity.
Andy
> On Oct 18, 2018, at 10:34 AM, Ian Lance Taylor wrote:
>
> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar
Quoting Andy Balholm (2018-10-18 14:00:52)
> That would also be a weakness of most of the other proposals,
> including my own to add operators to interfaces. Contracts are more
> powerful, at the expense of extra complexity.
Fwiw, my own proposal for "just using interfaces" covered the graph use
On Thu, Oct 18, 2018 at 12:28 PM Ian Denhardt wrote:
>
> Quoting Andy Balholm (2018-10-18 14:00:52)
>
> > That would also be a weakness of most of the other proposals,
> > including my own to add operators to interfaces. Contracts are more
> > powerful, at the expense of extra complexity.
>
>
I just tried this Google Playground recipe from Bradfritz:
https://play.golang.org/p/RYac90kI-H
(seen via https://github.com/golang/go/issues/21095)
and noted that y appears in the output but x appears as .
Can someone explain me why ? I was expecting that x appears in the same way
like y.
On Thu, Oct 18, 2018 at 10:37 PM Rusco wrote:
>
> I just tried this Google Playground recipe from Bradfritz:
>
> https://play.golang.org/p/RYac90kI-H
>
> (seen via https://github.com/golang/go/issues/21095)
>
> and noted that y appears in the output but x appears as .
>
> Can someone explain me
Providing a plugin (I prefer a separate binary called through rpc, but the
native .so is ok, too) is not a solution?
--
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
If you require that a single like type applies to all the labels in the
parameter declaration, such that func f(a, b T like int, c, d T2 like
string) means a and be must be like T's instantiating type, and c and d
must be like T2's unstantiating type, then you get that.
If you only require a
After reading his proposal, I think you should help Burak Sedar work out
his proposal in the other thread. It is conceptually a lot easier than the
idea of contracts, but likely to be more powerful even. To me it has the
ideal Go-like feel and it solves the problem with operator overloading in
On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote:
> The difference is that for generics, you *always* know the exact set of
> possible types that a type parameter can be.
>
If and only if you choose to do that analysis. AFAIK it is not currently
planned to do that
On Thu, 18 Oct 2018 at 06:44, Axel Wagner
wrote:
> This is only tangentially related to your specific idea, but I've decided
> that for generics discussions this is the hill I'm dying on:
>
> On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote:
>
>> The method calls in question can be inlined
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.
Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
>
The gomobile-gradle-plugin has been deprecated
(https://github.com/golang/mobile/commit/92f3b9caf7ba8f4f9c10074225afcba0cba47a62)
and the reverse-binding example is deleted
(https://github.com/golang/mobile/commit/2f2872eacd7fc12c252096592f87e9b23bd5be8b#diff-1a79a4d60de6718e8e5b326e338ae533)
On Thu, Oct 18, 2018 at 6:35 AM Robert Engels wrote:
>
> I meant to say contract not interface. Also as a user of said generic routine
> how do I know all of the available method on a type I would need to implement
> as I don’t know which ones the method may be using...
>
> Interfaces solve the
I think the problem with the proposal is that it is going to be very hard for
the compiler to know all of the operations a type can perform since for
concrete types the methods can be spread across multiple files. With an
interface it is only declared in a single location.
> On Oct 18, 2018,
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 exception of recursive generic
> functions, which can be
On Thu, 18 Oct 2018 at 08:40, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote:
>
>> The difference is that for generics, you *always* know the exact set of
>> possible types that a type parameter can be.
>>
>
> If and only if you choose to do that analysis. AFAIK it is
I meant to say contract not interface. Also as a user of said generic routine
how do I know all of the available method on a type I would need to implement
as I don’t know which ones the method may be using...
Interfaces solve the latter as I need to implement all of them in order to be
an
How so?
When you do
foo := foo.Foo{}
foo.Bar()
The compiler also has to look up Bar() for the type Foo, nothing special or
difficult about that. In Go, the places where the compiler has to look are
quite limited, I think. Furthermore with the currently proposed contracts,
much the same
On Tue, Oct 16, 2018 at 1:55 PM Matthias Schmidt
wrote:
>
> And here it is:
>
> https://github.com/ms140569/loki/releases/tag/1.2.0
Thanks for sharing this. I find this interesting because I've been
working on a very similar idea for an OIDC token manager CLI, and came
up with almost the same
Hi Burak,
and thanks pointing to you work. The memory-pinning was rather easy to
integrate, have a look:
https://github.com/ms140569/loki/commit/ad02ac092e56d4ac96ffaf8b737dac515516abfe
Timing-out the key-agent is something which came to my mind as well - i
guess i'll do it optionally.
I have not done much with golang on the web, so take this with a grain of
salt.
You are right in judging why it does not work - by the time the Javascript
runs, the template generation is long over with.
That said, I think you have two basic options:
Option 1: Front-load the data into
55 matches
Mail list logo
