[go-nuts] Re: Thinking OO virtual function in Go

[Haddock]

Am Dienstag, 22. November 2016 22:16:27 UTC+1 schrieb Tong Sun:
>
> Hi, 
>
> How to architect the OO's virtual function in Go? 
>
>
Here is another blog that shows a way how to do this: 
http://objectscape.blogspot.de/2013/09/inner-pattern-to-mimic-method.html 

-- 
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: multiple write headers problem

[Dave Cheney]

I think you problem is here

jsonReservations, err := 
jsonConvert.ReservationsJson(otherReservations)
if err != nil {
rw.WriteHeader(http.StatusExpectationFailed)
fmt.Println(err)
}

Instead try this

   if err != nil {
 http.Error(rw, err.Error(), http.StatusExpectationFailed)
 return // this is the important part
   }
   // do not allow execution to get to this line if err is != nil

On Thursday, 24 November 2016 11:44:13 UTC+11, gkol...@gmail.com wrote:
>
> Hey im running a go server locally using gorilla mux and net/http.
>
> For class we needed to create a room reservation system. I was testing the 
> application on multiple compyters on the same network but 
> when trying to create a reservation from both computer at the same time to 
> test concurrency I get a multiple write headers error. This problem does 
> not occur if i'm
> using the same computer but running on different browsers.
>
> It may help to know that the create button runs 2 ajax calls one to to 
> /readReservationByUserId as POST and to /createReservation as POST.
>
> func GetReservationsOthers(rw http.ResponseWriter, req *http.Request) {
> abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
> abstractTdg.GetConnection()
> defer abstractTdg.CloseConnection()
> defer req.Body.Close()
> req.ParseForm()
>
> roomID, err := strconv.Atoi(req.FormValue("dataRoom"))
> userID, err := strconv.Atoi(req.FormValue("userID"))
> reservationsMapper := mappers.MapperBundle.ReservationMapper
> reservations, err := reservationsMapper.GetByRoomId(roomID)
>
> otherReservations := 
> reservationsMapper.FilterOutUser(reservations, userID)
>
> if err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> fmt.Println(err)
> }
>
> jsonReservations, err := 
> jsonConvert.ReservationsJson(otherReservations)
> if err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> fmt.Println(err)
> }
> rw.Header().Set("Content-Type", "application/json")
> rw.Write(jsonReservations)
>
> }
>
> func CreateReservation(rw http.ResponseWriter, req *http.Request) {
> abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
> abstractTdg.GetConnection()
> defer abstractTdg.CloseConnection()
> req.ParseForm()
> roomId := req.FormValue("dataRoom")
> userId := req.FormValue("userID")
> startTime := req.FormValue("startTime")
> endTime := req.FormValue("endTime")
> roomIdint, _ := strconv.Atoi(roomId)
> userIDint, _ := strconv.Atoi(userId)
> startTimeformated, _ := time.Parse("2006-01-02 15:04:05", 
> startTime)
> endTimeformated, _ := time.Parse("2006-01-02 15:04:05", endTime)
> reservationMapper := mappers.MapperBundle.ReservationMapper
>
> if err := reservationMapper.Create(roomIdint, userIDint, 
> startTimeformated, endTimeformated); err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> }
>
> rw.WriteHeader(http.StatusOK)
> bytes, _ := jsonConvert.MessageJson("Success")
> rw.Write(bytes)
> }
>
>
>

-- 
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: Thinking OO virtual function in Go

[Tahir Hashmi]

On Wednesday, November 23, 2016 at 8:21:23 PM UTC+5:30, Tong Sun wrote:
 

> I've tried to derive how to achieve a) implementation inheritance, 
>> followed by b) type substitution and c) enabling dynamic dispatch as in 
>> virtual functions in my blog post here: 
>> https://tech.t9i.in/2014/01/22/inheritance-semantics-in-go/
>>
>  
> What's the fundamental difference between it and paraiso.marc's 
> implementation? 
> https://play.golang.org/p/o6Ot4IdJZ1
>
> My view is that GenHello() is just a fancy way of paraiso.marc's getters. 
> True?
>

The real difference is simulating the `this` pointer by defining the 
interface as a set of methods on itself. This allows modeling the interface 
purely on the desired common behaviour, whereas the getter approach 
requires including the getters in the interface out of necessity rather 
than need. It also precludes the possibility of adding more member fields 
in a "derived class" and using them in function overrides.

-- 
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] multiple write headers problem

[gkolampas]

Hey im running a go server locally using gorilla mux and net/http.

For class we needed to create a room reservation system. I was testing the 
application on multiple compyters on the same network but 
when trying to create a reservation from both computer at the same time to 
test concurrency I get a multiple write headers error. This problem does 
not occur if i'm
using the same computer but running on different browsers.

It may help to know that the create button runs 2 ajax calls one to to 
/readReservationByUserId as POST and to /createReservation as POST.

func GetReservationsOthers(rw http.ResponseWriter, req *http.Request) {
abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
abstractTdg.GetConnection()
defer abstractTdg.CloseConnection()
defer req.Body.Close()
req.ParseForm()

roomID, err := strconv.Atoi(req.FormValue("dataRoom"))
userID, err := strconv.Atoi(req.FormValue("userID"))
reservationsMapper := mappers.MapperBundle.ReservationMapper
reservations, err := reservationsMapper.GetByRoomId(roomID)

otherReservations := reservationsMapper.FilterOutUser(reservations, 
userID)

if err != nil {
rw.WriteHeader(http.StatusExpectationFailed)
fmt.Println(err)
}

jsonReservations, err := 
jsonConvert.ReservationsJson(otherReservations)
if err != nil {
rw.WriteHeader(http.StatusExpectationFailed)
fmt.Println(err)
}
rw.Header().Set("Content-Type", "application/json")
rw.Write(jsonReservations)

}

func CreateReservation(rw http.ResponseWriter, req *http.Request) {
abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
abstractTdg.GetConnection()
defer abstractTdg.CloseConnection()
req.ParseForm()
roomId := req.FormValue("dataRoom")
userId := req.FormValue("userID")
startTime := req.FormValue("startTime")
endTime := req.FormValue("endTime")
roomIdint, _ := strconv.Atoi(roomId)
userIDint, _ := strconv.Atoi(userId)
startTimeformated, _ := time.Parse("2006-01-02 15:04:05", startTime)
endTimeformated, _ := time.Parse("2006-01-02 15:04:05", endTime)
reservationMapper := mappers.MapperBundle.ReservationMapper

if err := reservationMapper.Create(roomIdint, userIDint, 
startTimeformated, endTimeformated); err != nil {
rw.WriteHeader(http.StatusExpectationFailed)
}

rw.WriteHeader(http.StatusOK)
bytes, _ := jsonConvert.MessageJson("Success")
rw.Write(bytes)
}


-- 
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: Why doens't function type support comparision but channel type does?

[Ian Lance Taylor]

On Wed, Nov 23, 2016 at 3:49 PM, roger peppe  wrote:
> Ian, what you say is true, but is also true of types and other objects too,
> I think. I found some interesting anomalies playing around with the new
> plugin package.

We've worked hard to make sure that what I said earlier is not true of
types, even in the presence of shared libraries.  If we've failed,
please file bugs.  Even with plugins it should work correctly.

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.

[go-nuts] Re: Frames for functions called via reflection are not shown in heap profiles

[alexei . alexandrov]

Let's just use https://github.com/google/pprof/issues/54 to avoid forking 
the discussion?

On Wednesday, November 23, 2016 at 2:25:59 PM UTC-8, Dave Cheney wrote:
>
> Please raise an issue on the issue tracker, golang.org/issue/new
>
> On Thursday, 24 November 2016 09:11:30 UTC+11, Alexey Alexandrov wrote:
>>
>> Hi Go team,
>>
>> We've got a report for pprof tool where call frames for functions called 
>> via reflection are not shown in the heap allocation profiles.  The cause 
>> turned out to be that all frames starting one matching "runtime\..*" regex 
>> and its callees are pruned for heap profiles today.  Reflected calls go via 
>> runtime.call32() and so get pruned.
>>
>> The discussion is at https://github.com/google/pprof/issues/54. 
>> Summoning up someone from Go team to comment on the proposed change to 
>> include runtime.call32 into the keep list.
>>
>

-- 
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: Why doens't function type support comparision but channel type does?

[roger peppe]

Ian, what you say is true, but is also true of types and other objects too,
I think. I found some interesting anomalies playing around with the new
plugin package.

Myself, I would have no objection to saying that two function values are
equal if they are defined by the same source code and use no variables in
outer non-global scopes. But I guess that would preclude certain compiler
optimisations that pull in variables that happen to have known constant
values.

I also wouldn't mind defining closure equality as undefined, but perhaps
best to steer away from more undefined behaviour.

  cheers,
rog.

On 23 Nov 2016 18:09, "Ian Lance Taylor"  wrote:

> On Wed, Nov 23, 2016 at 7:00 AM, T L  wrote:
> >
> > On Wednesday, November 23, 2016 at 10:35:59 PM UTC+8, Axel Wagner wrote:
> >>
> >> So, your suggestion is, to have functions be comparable, but have the
> >> comparisons always be false (unless compared to nil)? How would that be
> >> useful and *not* completely confusing? e.g. how would that not lead to
> >> people asking here, once a week, why (os.Open == os.Open) == false or
> >> something like that?
> >
> >
> > No, I don't os.Open != os.Open, they are the same question, so they are
> > equal.
>
> Even this seemingly simple statement is unclear.  Go now supports
> -buildmode=shared and -linkshared, meaning that a Go program can link
> against a set of shared libraries that are themselves written in Go.
> When running in this mode, a function like os.Open can easily appear
> multiple times in a single program image, in different shared
> libraries.  So while `os.Open == os.Open` might reasonably always be
> true, given
> func F() func(string) (*os.File, error) {
> return os.Open
> }
>
> then it is much less clear whether
>
> F() == os.Open
>
> should be true, as F might be in a shared library and might return a
> pointer to a different instance of os.Open.
>
> 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.
>

-- 
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] Frames for functions called via reflection are not shown in heap profiles

[aalexand via golang-nuts]

Hi Go team,

We've got a report for pprof tool where call frames for functions called 
via reflection are not shown in the heap allocation profiles.  The cause 
turned out to be that all frames starting one matching "runtime\..*" regex 
and its callees are pruned for heap profiles today.  Reflected calls go via 
runtime.call32() and so get pruned.

The discussion is at https://github.com/google/pprof/issues/54. Summoning 
up someone from Go team to comment on the proposed change to include 
runtime.call32 into the keep list.

-- 
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] Thinking OO virtual function in Go

[Nick Patavalis]

​
As I said
​ ​
before, Go's flavor of OO is different from that of other languages. Don't
try to map concepts one-to-one, or you will end up with very contrived
solutions. Always look at the big picture (why am I doing this?) and don't
get side-tracked by synthetic examples.

Most important is defining the correct interfaces (how your objects should
behave, what services they should provide); implementation reuse is
secondary. You will always find more than one ways to avoid repeating the
same code, on a per-case basis and you can always improve on that down the
way, provided that your interfaces are correct.

Just my 2c
/npat

-- 
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] Short Variable Declaration Question

[adonovan via golang-nuts]

On Friday, 18 November 2016 10:30:45 UTC-5, Ian Lance Taylor wrote:
>
> I think the book is trying to stress that it declares out but does not 
> declare err.  I agree that the sentence seems to imply that it does 
> not assign a value to out, but in fact it does both declare out and 
> assign a value to it. 
>

Indeed.  Apologies for the confusion.

(During copyediting, when reading aloud, I got into the habit of 
emphasizing the word immediately following "only" to help detect misplaced 
modifiers. In this instance the additional emphasis resolved the ambiguity 
the way I wanted it, but not the way one would normally read it.  Sigh.)

-- 
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] Thinking OO virtual function in Go

[Tong Sun]

On Wed, Nov 23, 2016 at 3:49 PM, Tong Sun wrote:

>
> On Wed, Nov 23, 2016 at 12:09 PM, Nick Patavalis wrote:
>
>> For this specific example, something like this:
>> https://play.golang.org/p/FsorWRaLKk
>>
>
> Thanks a lot Nick!
>
> I've simplified it a bit. Now it is:
>
> func (d Dog) Output() {
> // Presumably complicated stuff, not re-implemented
> d.Animal.Output(d.IsA())
> }
>
> I'm wondering if it is possible to somehow pass d.Speak as a function
> pointer to Animal.Output, so that inside Animal.Output, calling it will get
> to the correct dog.Speak or cat.Speak? Here is the code to start from:
>
> https://play.golang.org/p/cCmum-YRX9
>
> Thanks
>

I think I finally found the easiest way to make virtual function works,
based on Nick Patavalis code and Tahir Hashmi's idea:


func (a Animal) Output(s Speaker) {
// Complicated stuff that must not be re-implemented
fmt.Print("I am a ", s.IsA(),
". My name is ", a.Name,
", aged ", a.Age,
", it is ", a.IsMale,
" I am male.\n ")
s.Speak()
}


https://github.com/suntong/lang/blob/master/lang/Go/src/oo/Polymorphism-AnimalVF2.go

-- 
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] [ANN] RAIS: Fully open-source IIIF-compliant image server... and BONUS: the exciting story of how Go made its way into UO Libraries

[Ian Davis]

Great story and congrats on your project





On Wed, Nov 23, 2016, at 06:24 PM, Jeremy Echols wrote:

> *Project:*

> 

> This one's been out a long time, but I wanted to get to a place where
> it felt solid before announcing it to this list.  RAIS
> (https://github.com/uoregon-libraries/rais-image-server) is CC0-
> licensed and backs all the dynamic pan/zoom image-serving needs for
> Oregon Historic Newspapers (e.g.,
> http://oregonnews.uoregon.edu/lccn/sn94052322/1888-05-03/ed-1/seq-1/).
> 

> The project conforms to the IIIF Image 2.0 spec
> (http://iiif.io/api/image/2.0/), but its main purpose is serving JP2
> images as fast as possible, which it achieves with low-level CGO calls
> into libopenjpeg.  JP2 images are incredibly small for their quality,
> but decoding is notoriously slow.  Additionally, while there are very
> fast alternatives to JP2, very few are as space-efficient, and none
> are as memory-efficient.  For files in the 20-megapixel-plus range, we
> needed a format that doesn't require reading the whole image into
> memory, which tiled JP2 images do very well.
> 

> It's a pretty niche service, but I think its history tells a really
> great Go story even if nobody here has need of the service itself.
> 

> *Story:*

> 

> At the time RAIS was initially created, we had a pretty big problem:
> we had somewhere in the range of 30 terabytes of TIFFs backing our
> pan/zoom viewer, and we knew that number was only going up.  While we
> will always preserve the TIFF files (we're a library, it's what we
> do!), keeping them online at all times was far more expensive than,
> say, tape backups or a dark archive.  And, of course, reading TIFFs
> into memory meant 20+ megs of RAM **per request** (these are grayscale
> TIFFs for those about to say 20 megapixels should mean 60 megs of
> RAM).  During times of high traffic, RAM could become a significant
> bottleneck.
> 

> We considered pyramidal TIFFs with embedded JPGs and IIP image server,
> but found that we would "only" save about 80% on disk in order to get
> similar quality to the JP2 files we already had.  JP2 images, on the
> other hand, saved closer to 95% disk.
> 

> We considered pre-generating the tiles for about half a second.  But
> at the time we had about 500,000 individual newspaper pages.  Pre-
> generating of tiles would absolutely not work for us.  At least, not
> with any kind of disk savings.
> 

> We considered using proprietary JP2 libraries, which we knew could
> solve the problem really well.  But we wanted the software to be as
> open as possible.  One of our biggest contributions to the newspaper
> world was getting the software which runs our site open-sourced to
> begin with (it isn't something we wrote, just something we customized
> heavily, and convinced the authors to open-source).  Having done that
> work, we felt like it was a disservice to the community if we had to
> use proprietary software just to get the open-sourced software
> working.
> 

> We considered a slow JP2 server with a giant cache.  The software
> which runs the site *can* serve JP2 tiles without proprietary
> software... but the initial image can take 10+ seconds to load, and
> heavy traffic can make it almost unusable.  Hence, caching!  ...but
> can we get a lot more hits than misses?  Caching thumbnails turned out
> to be valuable for us, but tiles... not so much.  Looking at what was
> requested in the Apache logs, it seemed that the tiles served in any
> given week were mostly (75%) tiles that had *not* been served
> throughout the entire month.  Caching would certainly have some
> benefit, but a large number of our users would be hitting the very
> slow cache-miss pages, or else our cache would have been far too big
> to be feasible.
> 

> Sometime in late 2013 or early 2014, somebody at the Library of
> Congress showed us this project which he'd called "Brikker".  It was
> written months prior in Go as a proof-of-concept to solve similar
> problems to ours.  It required pulling a specific commit of openjpeg,
> manually patching it, and compiling it.  But it was capable of serving
> JP2 tiles dynamically, and the author claimed it was fairly
> performant.  We decided we should at least look into it, even though
> nobody knew Go and I for one was pretty skeptical of this silly "new"
> language.
> 

> We realized quickly that something like PHP or Python just wouldn't be
> able to do what Go could, at least not with anywhere near the same
> performance, and this use case was one which demanded performance.
> Calling into C is a bit of a pain in every language we considered, and
> the performance of the rest of the server could be an immediate
> bottleneck.  Better to stick with something that already appeared to
> have potential than take that risk.
> 

> So we dove into the world of Go, and slowly improved the original
> application until it could be put into production.
> 

> Now our TIFFs are somewhere far away from the web server and our 

Re: [go-nuts] Thinking OO virtual function in Go

[Tong Sun]

On Wed, Nov 23, 2016 at 12:09 PM, Nick Patavalis wrote:

> For this specific example, something like this: https://play.golang.org/p/
> FsorWRaLKk
>

Thanks a lot Nick!

I've simplified it a bit. Now it is:

func (d Dog) Output() {
// Presumably complicated stuff, not re-implemented
d.Animal.Output(d.IsA())
}

I'm wondering if it is possible to somehow pass d.Speak as a function
pointer to Animal.Output, so that inside Animal.Output, calling it will get
to the correct dog.Speak or cat.Speak? Here is the code to start from:

https://play.golang.org/p/cCmum-YRX9

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.

Re: [go-nuts] Thinking OO virtual function in Go

[Tong Sun]

Thanks Chad. This is beyond my understanding for the moment, but I'm sure
it'd be handy someday... Thanks.

On Wed, Nov 23, 2016 at 1:17 PM,  wrote:

> Sorry, didn't read the whole thread, but here's how I tackled inheritance
> in my cross compiler: https://play.golang.org/p/UDp7nSLyl2. Granted, I am
> unsure about the unsafe thing, but the concept of a "method dispatcher" is
> likely what you need.
>
>
> On Wednesday, November 23, 2016 at 11:09:03 AM UTC-6, Nick Patavalis wrote:
>>
>>
>> On Wednesday, November 23, 2016 at 5:17:11 PM UTC+2, Tong Sun wrote:
>>>
>>> Can you make it work on play.golang.org, from this code
>>> https://play.golang.org/p/QjCtD9rGpa, according to your plan?
>>>
>>
>> For this specific example, something like this:
>> https://play.golang.org/p/FsorWRaLKk
>>
>> /npat
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/f_62HEOIBV4/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Windows DPAPI Golang package

[Pietro Gagliardi]

That is the .net API; the equivalent C API is

https://msdn.microsoft.com/en-us/library/aa380261.aspx

Looking on godoc.org and github, I don't see any pre-made packages that 
implement this. However, you can use golang.org/x/sys/windows to call this 
function yourself.

https://github.com/search?q=cryptprotectdata+language%3Ago=Code shows that 
there are a few projects using htis internally, if you need some sample code.

Good luck!

> On Nov 23, 2016, at 7:54 AM, 'Jan Berktold' via golang-nuts 
>  wrote:
> 
> Hello everyone,
> 
> Does anyone know a Go package which provides an interface to the Windows Data 
> Protection API?
> 
> I am pretty much searching for the Go equivalent of this: 
> https://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata(v=vs.110).aspx
>  
> 
> 
> Thanks in advance
> 
> -- 
> 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] [ANN] RAIS: Fully open-source IIIF-compliant image server... and BONUS: the exciting story of how Go made its way into UO Libraries

[Jeremy Echols]

*Project:*

This one's been out a long time, but I wanted to get to a place where it 
felt solid before announcing it to this list.  RAIS 
(https://github.com/uoregon-libraries/rais-image-server) is CC0-licensed 
and backs all the dynamic pan/zoom image-serving needs for Oregon Historic 
Newspapers (e.g., 
http://oregonnews.uoregon.edu/lccn/sn94052322/1888-05-03/ed-1/seq-1/).

The project conforms to the IIIF Image 2.0 spec 
(http://iiif.io/api/image/2.0/), but its main purpose is serving JP2 images 
as fast as possible, which it achieves with low-level CGO calls into 
libopenjpeg.  JP2 images are incredibly small for their quality, but 
decoding is notoriously slow.  Additionally, while there are very fast 
alternatives to JP2, very few are as space-efficient, and none are as 
memory-efficient.  For files in the 20-megapixel-plus range, we needed a 
format that doesn't require reading the whole image into memory, which 
tiled JP2 images do very well.

It's a pretty niche service, but I think its history tells a really great 
Go story even if nobody here has need of the service itself.

*Story:*

At the time RAIS was initially created, we had a pretty big problem: we had 
somewhere in the range of 30 terabytes of TIFFs backing our pan/zoom 
viewer, and we knew that number was only going up.  While we will always 
preserve the TIFF files (we're a library, it's what we do!), keeping them 
online at all times was far more expensive than, say, tape backups or a 
dark archive.  And, of course, reading TIFFs into memory meant 20+ megs of 
RAM **per request** (these are grayscale TIFFs for those about to say 20 
megapixels should mean 60 megs of RAM).  During times of high traffic, RAM 
could become a significant bottleneck.

We considered pyramidal TIFFs with embedded JPGs and IIP image server, but 
found that we would "only" save about 80% on disk in order to get similar 
quality to the JP2 files we already had.  JP2 images, on the other hand, 
saved closer to 95% disk.

We considered pre-generating the tiles for about half a second.  But at the 
time we had about 500,000 individual newspaper pages.  Pre-generating of 
tiles would absolutely not work for us.  At least, not with any kind of 
disk savings.

We considered using proprietary JP2 libraries, which we knew could solve 
the problem really well.  But we wanted the software to be as open as 
possible.  One of our biggest contributions to the newspaper world was 
getting the software which runs our site open-sourced to begin with (it 
isn't something we wrote, just something we customized heavily, and 
convinced the authors to open-source).  Having done that work, we felt like 
it was a disservice to the community if we had to use proprietary software 
just to get the open-sourced software working.

We considered a slow JP2 server with a giant cache.  The software which 
runs the site *can* serve JP2 tiles without proprietary software... but the 
initial image can take 10+ seconds to load, and heavy traffic can make it 
almost unusable.  Hence, caching!  ...but can we get a lot more hits than 
misses?  Caching thumbnails turned out to be valuable for us, but tiles... 
not so much.  Looking at what was requested in the Apache logs, it seemed 
that the tiles served in any given week were mostly (75%) tiles that had 
*not* been served throughout the entire month.  Caching would certainly 
have some benefit, but a large number of our users would be hitting the 
very slow cache-miss pages, or else our cache would have been far too big 
to be feasible.

Sometime in late 2013 or early 2014, somebody at the Library of Congress 
showed us this project which he'd called "Brikker".  It was written months 
prior in Go as a proof-of-concept to solve similar problems to ours.  It 
required pulling a specific commit of openjpeg, manually patching it, and 
compiling it.  But it was capable of serving JP2 tiles dynamically, and the 
author claimed it was fairly performant.  We decided we should at least 
look into it, even though nobody knew Go and I for one was pretty skeptical 
of this silly "new" language.

We realized quickly that something like PHP or Python just wouldn't be able 
to do what Go could, at least not with anywhere near the same performance, 
and this use case was one which demanded performance.  Calling into C is a 
bit of a pain in every language we considered, and the performance of the 
rest of the server could be an immediate bottleneck.  Better to stick with 
something that already appeared to have potential than take that risk.

So we dove into the world of Go, and slowly improved the original 
application until it could be put into production.

Now our TIFFs are somewhere far away from the web server and our RAM usage 
is incredibly low.  During peak traffic, I've seen RAIS spike to about 400 
megs of RAM.  With load testing pushing its limits, it can even jump as 
high as a gig before CPU bottlenecks slow the requests down too much.  But 
our 

Re: [go-nuts] Thinking OO virtual function in Go

[chad . retz]

Sorry, didn't read the whole thread, but here's how I tackled inheritance 
in my cross compiler: https://play.golang.org/p/UDp7nSLyl2. Granted, I am 
unsure about the unsafe thing, but the concept of a "method dispatcher" is 
likely what you need.

On Wednesday, November 23, 2016 at 11:09:03 AM UTC-6, Nick Patavalis wrote:
>
>
> On Wednesday, November 23, 2016 at 5:17:11 PM UTC+2, Tong Sun wrote:
>>
>> Can you make it work on play.golang.org, from this code 
>> https://play.golang.org/p/QjCtD9rGpa, according to your plan?
>>
>
> For this specific example, something like this: 
> https://play.golang.org/p/FsorWRaLKk
>
> /npat
>
>

-- 
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: Why doens't function type support comparision but channel type does?

[Ian Lance Taylor]

On Wed, Nov 23, 2016 at 7:00 AM, T L  wrote:
>
> On Wednesday, November 23, 2016 at 10:35:59 PM UTC+8, Axel Wagner wrote:
>>
>> So, your suggestion is, to have functions be comparable, but have the
>> comparisons always be false (unless compared to nil)? How would that be
>> useful and *not* completely confusing? e.g. how would that not lead to
>> people asking here, once a week, why (os.Open == os.Open) == false or
>> something like that?
>
>
> No, I don't os.Open != os.Open, they are the same question, so they are
> equal.

Even this seemingly simple statement is unclear.  Go now supports
-buildmode=shared and -linkshared, meaning that a Go program can link
against a set of shared libraries that are themselves written in Go.
When running in this mode, a function like os.Open can easily appear
multiple times in a single program image, in different shared
libraries.  So while `os.Open == os.Open` might reasonably always be
true, given
func F() func(string) (*os.File, error) {
return os.Open
}

then it is much less clear whether

F() == os.Open

should be true, as F might be in a shared library and might return a
pointer to a different instance of os.Open.

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.

[go-nuts] Auto Generated Google API and boolean values

[Michael Mitton]

I am using the auto-generated google api client and ran in to a problem 
with unsuspending a user (via admin/directory/v1).  The Suspended field on 
the User object has the json tab omitempty and setting Suspended to false 
causes it not to get sent to the server.  In my local copy of the library I 
changed it to *bool which handles true/false/nil.  Should this be the 
default for all booleans in the API?  Throwing dereferences everywhere is 
ugly, but I don't know of a way to force json to send an empty field 
without taking omitempty away and if you take it away, sending PATCH 
requests will end up setting values you didn't want.

-Michael

-- 
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: Receiving results from a database

[Ondrej]

And in case you want to actually marshal it into a struct, I recommend 
giving JSON to Go a... go.

On Tuesday, 22 November 2016 20:48:49 UTC, vanmuld...@gmail.com wrote:
>
> I just started leaning Go and I've been stuck on this for a couple of days
>
> Running on an App Engine dev server
>
>
> The idea is to get an object I can work with with a format like this:
>
>
> {
>   "Results": [
> {
>   "username": "Test username",
>   "username_sani": "testusername",
>   "dob": "1992-09-10",
>   "email": "",
>   "gender": "M",
>   "account_type": "user",
>   "account_status": "enabled",
>   "activated": 1,
>   "country": "US",
>   "weekly_playtime": "6",
>   "game": [
> 
>   ],
>   "primary_game": "",
>   "activation_code": "BOxc9P2FomaaL4qKkQ2JMUIa1kgaYCJUlkfUqTs9",
>   "password": "",
>   "last_active": "2016-11-20 20:27:38",
>   "lol": {
> "verify_string": "ymn8Hm9ojfCzLqgZaZDi"
>   },
>   "login_history": [
> {
>   "date": "2016-11-20 20:03:46",
>   "result": "login_ok",   
>   "forward": "",
>   "timezone": -300
> }
>   ],
>   "current_login_att": 0,
>   "reset_password_entries": [
> {
>   "code": "sZln9bCoLYVrPXErKes5",
>   "valid_till": "2016-11-22 01:10",
>   "result": "cancelled"
> }
> }
>   ],
>   "Includes": [],
>   "IsStale": false,
>   "IndexTimestamp": "2016-11-21T16:21:06.5157187Z",
>   "TotalResults": 1,
>   "SkippedResults": 0,
>   "IndexName": "users_search",
>   "IndexEtag": "0100--0069--0001AED9",
>   "ResultEtag": "A85E1A89-3C87-F9AA-B0BA-41EC39CD225A",
>   "Highlightings": {},
>   "NonAuthoritativeInformation": false,
>   "LastQueryTime": "2016-11-22T19:19:39.0784570Z",
>   "DurationMilliseconds": 0,
>   "ScoreExplanations": {},
>   "TimingsInMilliseconds": {},
>   "ResultSize": 0
> }
>
>
> My current code :
>
>
> ctx := appengine.NewContext(req)
> client := urlfetch.Client(ctx)
> //
> resp,_ := client.Get(ip+"/indexes/"+ query)
> //
> doc,_ := ioutil.ReadAll(resp.Body)
> //
> resp.Body.Close();
> //
> var index_results IndexResults
> err := json.Unmarshal(doc,_results)
> if err != nil {
> log.Println(err)
> }
> log.Println(index_results) 
>
>
> Struct
> type IndexResults struct{
> Results []byte `json:"Results"`
> }
>
> Which gives me an error : json: cannot unmarshal object into Go value of 
> type uint8
> With result {[0]}
>
> How can I receive json results with dynamic fields that may or not be 
> there? Do I define a struct for every possible result?
>
> Thank you
>
>
>
>
>

-- 
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: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

(note: I'm exiting this thread now. I believe at this point it's reasonably
clear, that there are good reasons for this and anyone not convinced yet
won't be convinced by further arguments anyway)

On Wed, Nov 23, 2016 at 6:30 PM, Axel Wagner 
wrote:

> On Wed, Nov 23, 2016 at 4:30 PM, T L  wrote:
>
>> If two functions do completely different things, they mus be two
>> different functions.
>>
>
> No. An example has been given above, here is another one:
> https://play.golang.org/p/uNN0G4gzFm
>
>
>> Two different functions can also do the same thing, but they should be
>> not equal.
>>
>
> Why not? If someone who never read go code reads "f == g", why would they
> assume that this is your definition? Why wouldn't they get confused, that
> two functions who have the same definition (not "stem from the same
> declaration", but "contain the same code") are not equal?
>
> I agree that your definition is *consistent*. But it is still a) confusing
> for some cases and b) *not obviously the only sensible one*. Meaning,
> newcomers won't be able to infer from the expression, what it does. At all.
> (yes, go has similar problems elsewhere. But that doesn't mean, that we
> should pile on)
>
>
>>
>>
>>>
>>> Can you give a good justification of that behavior? And do you really
>>> think it won't confuse people like hell?
>>>
>>> One of the main reasons given for not making functions comparable, is
>>> that there is no good, intuitive notion of what "equality" means in the
>>> face of inlining and closures, so *no matter what behavior you choose*,
>>> people will be confused.
>>>
>>> On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:
>>>


 On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler
 wrote:
>
> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler
>> wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>
> That's basically is it: If functions are never equal so it is
> not sensible make them comparable.
>
> V.
>

 functions from the same declaration are equal.
 and function variables at the same address are equal.


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

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

On Wed, Nov 23, 2016 at 4:30 PM, T L  wrote:

> If two functions do completely different things, they mus be two different
> functions.
>

No. An example has been given above, here is another one:
https://play.golang.org/p/uNN0G4gzFm


> Two different functions can also do the same thing, but they should be not
> equal.
>

Why not? If someone who never read go code reads "f == g", why would they
assume that this is your definition? Why wouldn't they get confused, that
two functions who have the same definition (not "stem from the same
declaration", but "contain the same code") are not equal?

I agree that your definition is *consistent*. But it is still a) confusing
for some cases and b) *not obviously the only sensible one*. Meaning,
newcomers won't be able to infer from the expression, what it does. At all.
(yes, go has similar problems elsewhere. But that doesn't mean, that we
should pile on)


>
>
>>
>> Can you give a good justification of that behavior? And do you really
>> think it won't confuse people like hell?
>>
>> One of the main reasons given for not making functions comparable, is
>> that there is no good, intuitive notion of what "equality" means in the
>> face of inlining and closures, so *no matter what behavior you choose*,
>> people will be confused.
>>
>> On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:
>>
>>>
>>>
>>> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler
>>> wrote:

 Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>
>
>
> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler
> wrote:
>>
>> Just one argument out of many: Closures.
>> x := 3
>> f1 := func() int {
>> return x
>> }
>> f2 := func() int { return 3 }
>> // Is f1 == f2 ?
>>
>> x = 4
>> // What now? Still f1 == f2? Or never equal?
>>
>>
> Any bad to think then never equal?
>

 That's basically is it: If functions are never equal so it is
 not sensible make them comparable.

 V.

>>>
>>> functions from the same declaration are equal.
>>> and function variables at the same address are equal.
>>>
>>>
>>> --
>>> 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.

Re: [go-nuts] Thinking OO virtual function in Go

[Nick Patavalis]

On Wednesday, November 23, 2016 at 5:17:11 PM UTC+2, Tong Sun wrote:
>
> Can you make it work on play.golang.org, from this code 
> https://play.golang.org/p/QjCtD9rGpa, according to your plan?
>

For this specific example, something like this: 
https://play.golang.org/p/FsorWRaLKk

/npat

-- 
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] Why doens't function type support comparision but channel type does?

[Jan Mercl]

On Wed, Nov 23, 2016 at 6:00 PM T L  wrote:

>
>
> On Thursday, November 24, 2016 at 12:06:43 AM UTC+8, Jan Mercl wrote:
>
> On Wed, Nov 23, 2016 at 4:55 PM T L  wrote:
>
> > But we can't take addresses of formally declared functions and function
> literals.
>
> Yes, so if you cannot have the function pointer (like in func foo() {}; fp
> := foo) then there is nothing to compare so I don't understand what's the
> connection to comparing of function pointers.
>
>
> We cannot tabke addresses of constants too, but we can compare constants.
>

Constants have value that can be compared to some other value. Above quoted
from your earlier post is the correct observation that one cannot have a
function _value_ of a predeclared function or a function literal. So what
value comparison is now supposed to be analogical to comparing constants?
Put other way: In `if fv == whatever {}`, where the `fv` you are talking
about comes from, such that it has something in common to comparing
constants?

-- 

-j

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

On Thursday, November 24, 2016 at 12:06:43 AM UTC+8, Jan Mercl wrote:
>
> On Wed, Nov 23, 2016 at 4:55 PM T L  
> wrote:
>
> > But we can't take addresses of formally declared functions and function 
> literals.
>
> Yes, so if you cannot have the function pointer (like in func foo() {}; fp 
> := foo) then there is nothing to compare so I don't understand what's the 
> connection to comparing of function pointers.
>

We cannot tabke addresses of constants too, but we can compare constants.
 

>
> > We can only take addresses of function variables.
>
> Addresses of function variables can be compared freely without any 
> limitation. Note: There's a distinction between the value of a function 
> variable (that's the function pointer) and the address of the variable, 
> that's not the function address and so it can be compared normally. To be 
> explicit. Address of a function variable is a pointer to a pointer. Maybe 
> that's making this thread confusing.
>
>
> -- 
>
> -j
>

-- 
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] Windows DPAPI Golang package

['Jan Berktold' via golang-nuts]

Hello everyone,

Does anyone know a Go package which provides an interface to the Windows Data 
Protection API?

I am pretty much searching for the Go equivalent of this: 
https://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata(v=vs.110).aspx
 


Thanks in advance

-- 
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] Why doens't function type support comparision but channel type does?

[Jan Mercl]

On Wed, Nov 23, 2016 at 4:55 PM T L  wrote:

> But we can't take addresses of formally declared functions and function
literals.

Yes, so if you cannot have the function pointer (like in func foo() {}; fp
:= foo) then there is nothing to compare so I don't understand what's the
connection to comparing of function pointers.

> We can only take addresses of function variables.

Addresses of function variables can be compared freely without any
limitation. Note: There's a distinction between the value of a function
variable (that's the function pointer) and the address of the variable,
that's not the function address and so it can be compared normally. To be
explicit. Address of a function variable is a pointer to a pointer. Maybe
that's making this thread confusing.


-- 

-j

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 11:47:19 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Nov 23, 2016 at 4:28 PM T L  
> wrote:
>
> > Predeclared functions, including inlined ones, can be viewed as 
> constants, which have not addresses.
> > We can compare variable to constant, right?
>
> Wrong.
>
> Function pointers, specific Go implementation details aside for now, are 
> real pointers which you can use in the program to call the function it 
> points to. So making them "constants, which have not addresses" is not an 
> option.
>

But we can take addresses of formally declared functions and function 
literals.
We can only take addresses of function variables.


 

>
>
> -- 
>
> -j
>

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 11:47:19 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Nov 23, 2016 at 4:28 PM T L  
> wrote:
>
> > Predeclared functions, including inlined ones, can be viewed as 
> constants, which have not addresses.
> > We can compare variable to constant, right?
>
> Wrong.
>
> Function pointers, specific Go implementation details aside for now, are 
> real pointers which you can use in the program to call the function it 
> points to. So making them "constants, which have not addresses" is not an 
> option.
>


But we can't take addresses of formally declared functions and function 
literals.
We can only take addresses of function variables. 

>
>
> -- 
>
> -j
>

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 11:28:13 PM UTC+8, T L wrote:
>
>
>
> On Wednesday, November 23, 2016 at 11:18:02 PM UTC+8, Jan Mercl wrote:
>>
>> On Wed, Nov 23, 2016 at 3:30 PM T L  wrote:
>>
>> > Then? 
>>
>> Then there is nothing to compare. If a function is inlined then you 
>> cannot have a function pointer to it (like in func foo() {}; f := foo). So 
>> fully supporting comparing function pointers means disabling inlining of 
>> any function used in the f := foo or similar construct. Forbidding 
>> comparing functions to anything else than nil solves the problem.
>>
>
> Predeclared functions, including inlined ones, can be viewed as constants, 
> which have not addresses.
> We can compare variable to constant, right?
>

Here, for "Predeclared functions", I mean formally declared function, not 
the variable ones.
 

>  
>
>>
>> -- 
>>
>> -j
>>
>

-- 
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] Why doens't function type support comparision but channel type does?

[Jan Mercl]

On Wed, Nov 23, 2016 at 4:28 PM T L  wrote:

> Predeclared functions, including inlined ones, can be viewed as
constants, which have not addresses.
> We can compare variable to constant, right?

Wrong.

Function pointers, specific Go implementation details aside for now, are
real pointers which you can use in the program to call the function it
points to. So making them "constants, which have not addresses" is not an
option.


-- 

-j

-- 
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: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 11:11:24 PM UTC+8, Axel Wagner wrote:
>
> So, even though two functions do completely different things, you still 
> want to have them equal? And even though two other functions do completely 
> the same thing, they should be different?
>

If two functions do completely different things, they mus be two different 
functions.
Two different functions can also do the same thing, but they should be not 
equal.
 

>
> Can you give a good justification of that behavior? And do you really 
> think it won't confuse people like hell?
>
> One of the main reasons given for not making functions comparable, is that 
> there is no good, intuitive notion of what "equality" means in the face of 
> inlining and closures, so *no matter what behavior you choose*, people will 
> be confused.
>
> On Wed, Nov 23, 2016 at 4:01 PM, T L  
> wrote:
>
>>
>>
>> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>>>
>>> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:



 On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler 
 wrote:
>
> Just one argument out of many: Closures.
> x := 3
> f1 := func() int {
> return x
> }
> f2 := func() int { return 3 }
> // Is f1 == f2 ?
>
> x = 4
> // What now? Still f1 == f2? Or never equal?
>
>
 Any bad to think then never equal?

>>>
>>> That's basically is it: If functions are never equal so it is
>>> not sensible make them comparable.
>>>
>>> V.
>>>
>>
>> functions from the same declaration are equal.
>> and function variables at the same address are equal.
>>  
>>
>> -- 
>> 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] Thinking OO virtual function in Go

[Nick Patavalis]

Yes... so every specific animal type implements it's own Output() method,
which does the trivial IsA() part, and calls Animal's Output() for the
common complicated parts...

On Nov 23, 2016 16:35, "Tong Sun"  wrote:

> Have you noticed the IsA() func call there?
>
> On Wed, Nov 23, 2016 at 4:05 AM, Nick Patavalis 
> wrote:
>
>> Hi,
>>
>> In your *second* example, making Output() a method of Animal will work,
>> since it uses only the members (fields) of Animal, and not the fields of
>> specific animals (or any behavior that varies between animals). That's why
>> I'm insisting on *real* and *specific* examples, not synthetic ones.
>>
>> /npat
>>
>> On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote:
>>>
>>> No Nick, making Output() a member method won't work.
>>> See my OP and Jesse's answer. I.e., I have to change it from a member
>>> function to a pure function.
>>>
>>> On Tue, Nov 22, 2016 at 6:25 PM, Nick Patavalis 
>>> wrote:
>>>
 Hi,

 There is no direct mapping of what you can do with virtual functions in
 other OO languages, and Go. There are different compromises you have to
 make; because of this, synthetic examples will probably not help much.

 That being said, in the case of your last example I would make Output()
 a method of Animal.
 The Speak() methods of the specific animals would then call Output().

 /npat

 On Wednesday, November 23, 2016 at 12:03:54 AM UTC+2, Tong Sun wrote:
>
>
>
> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>
>> On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
>> > Hi,
>> >
>> > How to architect the OO's virtual function in Go?
>> >
>> > Please take a look at this (not working) Go program
>> > https://play.golang.org/p/qrBX6ScABp
>> >
>> > Please think of the "func Output()" as a very complicated function
>> that I
>> > only want to define once at the base level, not to duplicate into
>> each sub
>> > classes.
>> >
>> > How can I make it works so that the last output statement, instead
>> of being,
>> >
>> > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>> >
>> >
>> > will be this instead:
>> >
>> > fmt.Printf("[%v] %s\n", k, v.Output())
>> >
>>
>> You define a function:
>>
>> func Output(s Shape) string {
>>return s.Name() + "'s area size is " + s.Area()
>> }
>>
>> Go uses interfaces for polymorphism.
>> Other OOP languages can use inheritance for polymorphism too, but Go
>> doesn't have inheritance.
>>
>
> Thanks Jesse. That works.
>
> However I just realized that it is only part of my problem.
>
> I have a huge list of common variables that I defined in my "base
> class", changing it from a member function to a pure function causes 
> almost
> every single variable now undefined.
>
> I can demonstrate the problem with this code
> https://play.golang.org/p/QjCtD9rGpa
>
> So, once again, thinking in OO, I'll define all of the common
> variables in base class, and common functionalities in virtual functions.
> How to make that idea work in Go?
>
> For the above specific code, how to easily make "func Output" works?
>
> Thanks
>
> --
 You received this message because you are subscribed to a topic in the
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit https://groups.google.com/d/to
 pic/golang-nuts/f_62HEOIBV4/unsubscribe.
 To unsubscribe from this group and all its topics, 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 a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/f_62HEOIBV4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] Thinking OO virtual function in Go

[Tong Sun]

Oh, I think you might not have notice this request from OP:

Please think of the "func Output()" as a very complicated function that I
> only want to define *once *at the base level, not to duplicate into each
> sub classes.



On Wed, Nov 23, 2016 at 10:16 AM, Tong Sun  wrote:

> Can you make it work on play.golang.org, from this code
> https://play.golang.org/p/QjCtD9rGpa, according to your plan?
>
> On Wed, Nov 23, 2016 at 10:14 AM, Nick Patavalis  > wrote:
>
>> Yes... so every specific animal type implements it's own Output() method,
>> which does the trivial IsA() part, and calls Animal's Output() for the
>> common complicated parts...
>>
>> On Nov 23, 2016 16:35, "Tong Sun"  wrote:
>>
>>> Have you noticed the IsA() func call there?
>>>
>>> On Wed, Nov 23, 2016 at 4:05 AM, Nick Patavalis <
>>> nick.patava...@gmail.com> wrote:
>>>
 Hi,

 In your *second* example, making Output() a method of Animal will work,
 since it uses only the members (fields) of Animal, and not the fields of
 specific animals (or any behavior that varies between animals). That's why
 I'm insisting on *real* and *specific* examples, not synthetic ones.

 /npat

 On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote:
>
> No Nick, making Output() a member method won't work.
> See my OP and Jesse's answer. I.e., I have to change it from a member
> function to a pure function.
>
> On Tue, Nov 22, 2016 at 6:25 PM, Nick Patavalis 
> wrote:
>
>> Hi,
>>
>> There is no direct mapping of what you can do with virtual functions
>> in other OO languages, and Go. There are different compromises you have 
>> to
>> make; because of this, synthetic examples will probably not help much.
>>
>> That being said, in the case of your last example I would make
>> Output() a method of Animal.
>> The Speak() methods of the specific animals would then call Output().
>>
>> /npat
>>
>> On Wednesday, November 23, 2016 at 12:03:54 AM UTC+2, Tong Sun wrote:
>>>
>>>
>>>
>>> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>>>
 On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
 > Hi,
 >
 > How to architect the OO's virtual function in Go?
 >
 > Please take a look at this (not working) Go program
 > https://play.golang.org/p/qrBX6ScABp
 >
 > Please think of the "func Output()" as a very complicated
 function that I
 > only want to define once at the base level, not to duplicate into
 each sub
 > classes.
 >
 > How can I make it works so that the last output statement,
 instead of being,
 >
 > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
 >
 >
 > will be this instead:
 >
 > fmt.Printf("[%v] %s\n", k, v.Output())
 >

 You define a function:

 func Output(s Shape) string {
return s.Name() + "'s area size is " + s.Area()
 }

 Go uses interfaces for polymorphism.
 Other OOP languages can use inheritance for polymorphism too, but Go
 doesn't have inheritance.

>>>
>>> Thanks Jesse. That works.
>>>
>>> However I just realized that it is only part of my problem.
>>>
>>> I have a huge list of common variables that I defined in my "base
>>> class", changing it from a member function to a pure function causes 
>>> almost
>>> every single variable now undefined.
>>>
>>> I can demonstrate the problem with this code
>>> https://play.golang.org/p/QjCtD9rGpa
>>>
>>> So, once again, thinking in OO, I'll define all of the common
>>> variables in base class, and common functionalities in virtual 
>>> functions.
>>> How to make that idea work in Go?
>>>
>>> For the above specific code, how to easily make "func Output" works?
>>>
>>> Thanks
>>>
>>> --
>> You received this message because you are subscribed to a topic in
>> the Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/f_62HEOIBV4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 a topic in the
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit https://groups.google.com/d/to
 pic/golang-nuts/f_62HEOIBV4/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 golang-nuts+unsubscr...@googlegroups.com.
 For 

Re: [go-nuts] Why doens't function type support comparision but channel type does?

[Jan Mercl]

On Wed, Nov 23, 2016 at 3:30 PM T L  wrote:

> Then?

Then there is nothing to compare. If a function is inlined then you cannot
have a function pointer to it (like in func foo() {}; f := foo). So fully
supporting comparing function pointers means disabling inlining of any
function used in the f := foo or similar construct. Forbidding comparing
functions to anything else than nil solves the problem.

-- 

-j

-- 
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] Thinking OO virtual function in Go

[Tong Sun]

Can you make it work on play.golang.org, from this code
https://play.golang.org/p/QjCtD9rGpa, according to your plan?

On Wed, Nov 23, 2016 at 10:14 AM, Nick Patavalis 
wrote:

> Yes... so every specific animal type implements it's own Output() method,
> which does the trivial IsA() part, and calls Animal's Output() for the
> common complicated parts...
>
> On Nov 23, 2016 16:35, "Tong Sun"  wrote:
>
>> Have you noticed the IsA() func call there?
>>
>> On Wed, Nov 23, 2016 at 4:05 AM, Nick Patavalis > > wrote:
>>
>>> Hi,
>>>
>>> In your *second* example, making Output() a method of Animal will work,
>>> since it uses only the members (fields) of Animal, and not the fields of
>>> specific animals (or any behavior that varies between animals). That's why
>>> I'm insisting on *real* and *specific* examples, not synthetic ones.
>>>
>>> /npat
>>>
>>> On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote:

 No Nick, making Output() a member method won't work.
 See my OP and Jesse's answer. I.e., I have to change it from a member
 function to a pure function.

 On Tue, Nov 22, 2016 at 6:25 PM, Nick Patavalis 
 wrote:

> Hi,
>
> There is no direct mapping of what you can do with virtual functions
> in other OO languages, and Go. There are different compromises you have to
> make; because of this, synthetic examples will probably not help much.
>
> That being said, in the case of your last example I would make
> Output() a method of Animal.
> The Speak() methods of the specific animals would then call Output().
>
> /npat
>
> On Wednesday, November 23, 2016 at 12:03:54 AM UTC+2, Tong Sun wrote:
>>
>>
>>
>> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>>
>>> On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
>>> > Hi,
>>> >
>>> > How to architect the OO's virtual function in Go?
>>> >
>>> > Please take a look at this (not working) Go program
>>> > https://play.golang.org/p/qrBX6ScABp
>>> >
>>> > Please think of the "func Output()" as a very complicated function
>>> that I
>>> > only want to define once at the base level, not to duplicate into
>>> each sub
>>> > classes.
>>> >
>>> > How can I make it works so that the last output statement, instead
>>> of being,
>>> >
>>> > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>>> >
>>> >
>>> > will be this instead:
>>> >
>>> > fmt.Printf("[%v] %s\n", k, v.Output())
>>> >
>>>
>>> You define a function:
>>>
>>> func Output(s Shape) string {
>>>return s.Name() + "'s area size is " + s.Area()
>>> }
>>>
>>> Go uses interfaces for polymorphism.
>>> Other OOP languages can use inheritance for polymorphism too, but Go
>>> doesn't have inheritance.
>>>
>>
>> Thanks Jesse. That works.
>>
>> However I just realized that it is only part of my problem.
>>
>> I have a huge list of common variables that I defined in my "base
>> class", changing it from a member function to a pure function causes 
>> almost
>> every single variable now undefined.
>>
>> I can demonstrate the problem with this code
>> https://play.golang.org/p/QjCtD9rGpa
>>
>> So, once again, thinking in OO, I'll define all of the common
>> variables in base class, and common functionalities in virtual functions.
>> How to make that idea work in Go?
>>
>> For the above specific code, how to easily make "func Output" works?
>>
>> Thanks
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/golang-nuts/f_62HEOIBV4/unsubscribe.
> To unsubscribe from this group and all its topics, 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 a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/golang-nuts/f_62HEOIBV4/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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] Re: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

So, even though two functions do completely different things, you still
want to have them equal? And even though two other functions do completely
the same thing, they should be different?

Can you give a good justification of that behavior? And do you really think
it won't confuse people like hell?

One of the main reasons given for not making functions comparable, is that
there is no good, intuitive notion of what "equality" means in the face of
inlining and closures, so *no matter what behavior you choose*, people will
be confused.

On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:

>
>
> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>>
>> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>>
>>>
>>>
>>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:

 Just one argument out of many: Closures.
 x := 3
 f1 := func() int {
 return x
 }
 f2 := func() int { return 3 }
 // Is f1 == f2 ?

 x = 4
 // What now? Still f1 == f2? Or never equal?


>>> Any bad to think then never equal?
>>>
>>
>> That's basically is it: If functions are never equal so it is
>> not sensible make them comparable.
>>
>> V.
>>
>
> functions from the same declaration are equal.
> and function variables at the same address are equal.
>
>
> --
> 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: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>
> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>
> That's basically is it: If functions are never equal so it is
> not sensible make them comparable.
>
> V.
>

functions from the same declaration are equal.
and function variables at the same address are equal.
 

-- 
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: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 10:35:59 PM UTC+8, Axel Wagner wrote:
>
> So, your suggestion is, to have functions be comparable, but have the 
> comparisons always be false (unless compared to nil)? How would that be 
> useful and *not* completely confusing? e.g. how would that not lead to 
> people asking here, once a week, why (os.Open == os.Open) == false or 
> something like that?
>

No, I don't os.Open != os.Open, they are the same question, so they are 
equal. 
I just mean comparing different functions always returns false.
 

>
> On Wed, Nov 23, 2016 at 3:30 PM, T L  
> wrote:
>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>>  
>>
>>> V.
>>>
>>> -- 
>> 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: Thinking OO virtual function in Go

[Tong Sun]

On Wed, Nov 23, 2016 at 8:52 AM, Tahir Hashmi wrote:

>
> I also like the approach suggested by Sebastien Binet. It's really neat in
> situations where you can get by without needing to override the base
> implementation (e.g. of Shape.Output()).
>

That it is only a partial solution -- I have a huge list of common
variables that I defined in my "base class", changing it from a member
function to a pure function causes almost every single variable now
undefined.

I've tried to derive how to achieve a) implementation inheritance, followed
> by b) type substitution and c) enabling dynamic dispatch as in virtual
> functions in my blog post here: https://tech.t9i.in/
> 2014/01/22/inheritance-semantics-in-go/
>

What's the fundamental difference between it and paraiso.marc's
implementation?
https://play.golang.org/p/o6Ot4IdJZ1

My view is that GenHello() is just a fancy way of paraiso.marc's getters.
True?

On Wednesday, November 23, 2016 at 2:46:27 AM UTC+5:30, Tong Sun wrote:
>>
>> Hi,
>>
>> How to architect the OO's virtual function in Go?
>>
>> Please take a look at this (not working) Go program
>> https://play.golang.org/p/qrBX6ScABp
>>
>> Please think of the "func Output()" as a very complicated function that I
>> only want to define *once *at the base level, not to duplicate into each
>> sub classes.
>>
>> How can I make it works so that the last output statement, instead of
>> being,
>>
>> fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>>
>>
>> will be this instead:
>>
>> fmt.Printf("[%v] %s\n", k, v.Output())
>>
>>
>> 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.

[go-nuts] Re: Why doens't function type support comparision but channel type does?

[Volker Dobler]

Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>
>
>
> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>
>> Just one argument out of many: Closures.
>> x := 3
>> f1 := func() int {
>> return x
>> }
>> f2 := func() int { return 3 }
>> // Is f1 == f2 ?
>>
>> x = 4
>> // What now? Still f1 == f2? Or never equal?
>>
>>
> Any bad to think then never equal?
>

That's basically is it: If functions are never equal so it is
not sensible make them comparable.

V.

-- 
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] Thinking OO virtual function in Go

[Tong Sun]

Have you noticed the IsA() func call there?

On Wed, Nov 23, 2016 at 4:05 AM, Nick Patavalis 
wrote:

> Hi,
>
> In your *second* example, making Output() a method of Animal will work,
> since it uses only the members (fields) of Animal, and not the fields of
> specific animals (or any behavior that varies between animals). That's why
> I'm insisting on *real* and *specific* examples, not synthetic ones.
>
> /npat
>
> On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote:
>>
>> No Nick, making Output() a member method won't work.
>> See my OP and Jesse's answer. I.e., I have to change it from a member
>> function to a pure function.
>>
>> On Tue, Nov 22, 2016 at 6:25 PM, Nick Patavalis 
>> wrote:
>>
>>> Hi,
>>>
>>> There is no direct mapping of what you can do with virtual functions in
>>> other OO languages, and Go. There are different compromises you have to
>>> make; because of this, synthetic examples will probably not help much.
>>>
>>> That being said, in the case of your last example I would make Output()
>>> a method of Animal.
>>> The Speak() methods of the specific animals would then call Output().
>>>
>>> /npat
>>>
>>> On Wednesday, November 23, 2016 at 12:03:54 AM UTC+2, Tong Sun wrote:



 On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:

> On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
> > Hi,
> >
> > How to architect the OO's virtual function in Go?
> >
> > Please take a look at this (not working) Go program
> > https://play.golang.org/p/qrBX6ScABp
> >
> > Please think of the "func Output()" as a very complicated function
> that I
> > only want to define once at the base level, not to duplicate into
> each sub
> > classes.
> >
> > How can I make it works so that the last output statement, instead
> of being,
> >
> > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
> >
> >
> > will be this instead:
> >
> > fmt.Printf("[%v] %s\n", k, v.Output())
> >
>
> You define a function:
>
> func Output(s Shape) string {
>return s.Name() + "'s area size is " + s.Area()
> }
>
> Go uses interfaces for polymorphism.
> Other OOP languages can use inheritance for polymorphism too, but Go
> doesn't have inheritance.
>

 Thanks Jesse. That works.

 However I just realized that it is only part of my problem.

 I have a huge list of common variables that I defined in my "base
 class", changing it from a member function to a pure function causes almost
 every single variable now undefined.

 I can demonstrate the problem with this code
 https://play.golang.org/p/QjCtD9rGpa

 So, once again, thinking in OO, I'll define all of the common variables
 in base class, and common functionalities in virtual functions. How to make
 that idea work in Go?

 For the above specific code, how to easily make "func Output" works?

 Thanks

 --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/golang-nuts/f_62HEOIBV4/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/f_62HEOIBV4/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>
> Just one argument out of many: Closures.
> x := 3
> f1 := func() int {
> return x
> }
> f2 := func() int { return 3 }
> // Is f1 == f2 ?
>
> x = 4
> // What now? Still f1 == f2? Or never equal?
>
>
Any bad to think then never equal?

 

> V.
>
>

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 9:45:56 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Nov 23, 2016 at 2:40 PM T L  
> wrote:
>
> Functions can be inlined.
>
> -- 
>
> -j
>

Then? 

Is there any problem to think no two functions can be equal?

-- 
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] Why doens't function type support comparision but channel type does?

['chris dollin' via golang-nuts]

If functions are comparable you have to be very
careful in defining /when/ they are equal.

func f(x int)int {return x+2}
func g(x int)int {return x+2}
func h(x int)int {return x+1+1}

Are f and g equal? f and h?

func k() func (int)int { return func(int x)int {x + 1}}

Are k() and k() equal? f and k()?

var x = 17
func l() func(int)int {y := 2; return func(int x)int {x +y}}

l() and f? and k()? and l()?

Disallowing equality tests on functions allows the
compiler to freely re-use code (or not).

Chris

-- 
Chris "allusive" Dollin

-- 
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: Where should interfaces live?

[Vorn Mom]

Great responses. Thanks!  I think what it comes down to is there's two main 
definition/use cases of an interface:

   - The inheritance-based one that you find in Java and C# where the 
   interface provides an contract into various implementations.   The design 
   is typically API-driven and you would approach the problem by defining the 
   interface first.  It's usually defined in its own package.
   - The other is when you're writing code that depends on an external 
   dependency and you want to hide it behind an interface.  This was not 
   practical in Java / C# because of the inheritance-based interface, and 
   showcases the power of Go interfaces.  It's usually defined in the package 
   that needs it.

Both use cases are valid depending on what you're building and both are 
possible in Go.

On Monday, November 21, 2016 at 10:30:21 AM UTC-5, Vorn Mom wrote:
>
> Sorry if it was asked before, but where should interfaces live?
>
>- In the package that contains an implementation of it.
>- In its own package.
>- or in the package that needs it.
>
> The standard library is not consistent.  For example:
>
>- io.Writer is defined in a package that also has an implementation, 
>io.PipeWriter.  
>- Encoding is all interfaces, defering implementation to sub-packages.
>- database/sql returns a DB struct on Open() instead of an interface.
>
> Because Go interfaces are decoupled from implementation, I think it should 
> be defined where it's needed.  So I like having my own interface for DB 
> that may only define a subset of what behaviors it provides.
>
> However, doesn't defining an interface that depends on other packages 
> decrease cohesion and leaks the abstraction?  For example,
>
> type interface DbQuery {
>   QueryRow(query string, args ...interface{}) *sql.Row
> }
>
> This interface depends on sql.Row.  This decreases cohesion because the 
> interface is now defined across packages?
>
> -Vorn
>
>
>

-- 
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: Why doens't function type support comparision but channel type does?

[Volker Dobler]

Just one argument out of many: Closures.
x := 3
f1 := func() int {
return x
}
f2 := func() int { return 3 }
// Is f1 == f2 ?

x = 4
// What now? Still f1 == f2? Or never equal?

V.

-- 
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: Thinking OO virtual function in Go

[Tahir Hashmi]

I've tried to derive how to achieve a) implementation inheritance, followed 
by b) type substitution and c) enabling dynamic dispatch as in virtual 
functions in my blog post 
here: https://tech.t9i.in/2014/01/22/inheritance-semantics-in-go/

I also like the approach suggested by Sebastien Binet. It's really neat in 
situations where you can get by without needing to override the base 
implementation (e.g. of Shape.Output()).

On Wednesday, November 23, 2016 at 2:46:27 AM UTC+5:30, Tong Sun wrote:
>
> Hi, 
>
> How to architect the OO's virtual function in Go? 
>
> Please take a look at this (not working) Go program
> https://play.golang.org/p/qrBX6ScABp
>
> Please think of the "func Output()" as a very complicated function that I 
> only want to define *once *at the base level, not to duplicate into each 
> sub classes. 
>
> How can I make it works so that the last output statement, instead of 
> being, 
>
> fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>
>
> will be this instead:
>
> fmt.Printf("[%v] %s\n", k, v.Output())
>
>
> 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.

Re: [go-nuts] Why doens't function type support comparision but channel type does?

[Jan Mercl]

On Wed, Nov 23, 2016 at 2:40 PM T L  wrote:

Functions can be inlined.

-- 

-j

-- 
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] Why doens't function type support comparision but channel type does?

[T L]

.

-- 
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] err variable shadowing — is it a bad practice?

[Steven Hartland]

I believe vet shadow is known to have issues and is quite picky ;-)

Your first one I'd say could be classed as bug as you're clearly 
declaring n however I'd guess this is due to the for loop as declaring n 
out of the loop eliminating the short declaration will fix it. This is 
confirmed by eliminating the for which also eliminates the warning.


Your second warning (|cat.go:33) |I'd say is correct as you don't 
declare a new variable hence err is declared unnecessarily. I'm not sure 
if go will actually redeclare a new var under the hood, but as err is 
already available just reuse it.



On 23/11/2016 10:46, iakov.davy...@gmail.com wrote:

Hi,
Occasionally go vet complains about shadowing of the err variable.
Consider the following code.

|
package main

import (
"flag"
"io"
"os"
)

func main() {
inFilename := flag.String("in", "infile", "input file")
outFilename := flag.String("out", "outfile", "output file")
flag.Parse()

in, err := os.Open(*inFilename)
if err != nil {
panic(err)
}

out, err := os.Create(*outFilename)
if err != nil {
panic(err)
}

buf := make([]byte, 1024)
for {
n, err := in.Read(buf)
if err != nil && err != io.EOF {
panic(err)
}
if n == 0 {
break
}
if _, err := out.Write(buf[:n]); err != nil {
panic(err)
}
}
}

|

Go vet in strict mode complains:

|
$ go tool vet -shadow -shadowstrict ./cat.go
./cat.go:26: declaration of "err" shadows declaration at ./cat.go:14
./cat.go:33: declaration of "err" shadows declaration at ./cat.go:26
|

Is it really a bad practice? What's the alternative?
Declaring all the variables in advance with explicitly specifying 
their types, i.e.


|
var out *os.File
out, err = os.Create(*outFilename)
|
?

Thanks,
Iakov
--
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] err variable shadowing — is it a bad practice?

[Dave Cheney]

This is extremely common in go code, vet is being pedantic,

-- 
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] Thinking OO virtual function in Go

[Nick Patavalis]

Hi,

In your *second* example, making Output() a method of Animal will work, 
since it uses only the members (fields) of Animal, and not the fields of 
specific animals (or any behavior that varies between animals). That's why 
I'm insisting on *real* and *specific* examples, not synthetic ones.

/npat

On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote:
>
> No Nick, making Output() a member method won't work. 
> See my OP and Jesse's answer. I.e., I have to change it from a member 
> function to a pure function. 
>
> On Tue, Nov 22, 2016 at 6:25 PM, Nick Patavalis  > wrote:
>
>> Hi,
>>
>> There is no direct mapping of what you can do with virtual functions in 
>> other OO languages, and Go. There are different compromises you have to 
>> make; because of this, synthetic examples will probably not help much. 
>>
>> That being said, in the case of your last example I would make Output() a 
>> method of Animal. 
>> The Speak() methods of the specific animals would then call Output().
>>
>> /npat
>>
>> On Wednesday, November 23, 2016 at 12:03:54 AM UTC+2, Tong Sun wrote:
>>>
>>>
>>>
>>> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>>>
 On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
 > Hi,
 >
 > How to architect the OO's virtual function in Go?
 >
 > Please take a look at this (not working) Go program
 > https://play.golang.org/p/qrBX6ScABp
 >
 > Please think of the "func Output()" as a very complicated function 
 that I
 > only want to define once at the base level, not to duplicate into 
 each sub
 > classes.
 >
 > How can I make it works so that the last output statement, instead of 
 being,
 >
 > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
 >
 >
 > will be this instead:
 >
 > fmt.Printf("[%v] %s\n", k, v.Output())
 >

 You define a function:

 func Output(s Shape) string {
return s.Name() + "'s area size is " + s.Area()
 }

 Go uses interfaces for polymorphism.
 Other OOP languages can use inheritance for polymorphism too, but Go
 doesn't have inheritance.

>>>
>>> Thanks Jesse. That works. 
>>>
>>> However I just realized that it is only part of my problem. 
>>>
>>> I have a huge list of common variables that I defined in my "base 
>>> class", changing it from a member function to a pure function causes almost 
>>> every single variable now undefined. 
>>>
>>> I can demonstrate the problem with this code
>>> https://play.golang.org/p/QjCtD9rGpa
>>>
>>> So, once again, thinking in OO, I'll define all of the common variables 
>>> in base class, and common functionalities in virtual functions. How to make 
>>> that idea work in Go?
>>>
>>> For the above specific code, how to easily make "func Output" works?
>>>
>>> Thanks
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/f_62HEOIBV4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.