Not go specific, there are inotifywait and entr http://eradman.com/entrproject/.
In go you would need something like this:
https://github.com/fsnotify/fsnotify
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
A small gui library is not that much work. Here is my work in progress:
https://gitlab.com/beoran/ebsgo/tree/master/zori
It's sleepycat licensed, and uses Allegro as a backend, but it could be made
multi backend as well. I am willing to make it MIT if anyone else would like to
join.
Or just use
I'd say it's a useful feature, but not in it 's current form. I rather than
dropping the featture I'd like to see it enhanced so so it works as well as
a pascal .unit file does as a binary package for a high level language.
This also points to a solution as well, have a .gobin file that is an
Let's get serious about this. I started a GitHub repository to work on this
proposal. https://github.com/beoran/go-like-generics-proposal/
You are all cordially invited to help out fleshing out this proposal.
--
You received this message because you are subscribed to the Google Groups
"g
How so?
When you do
foo := foo.Foo{}
foo.Bar()
The compiler also has to look up Bar() for the type Foo, nothing special or
difficult about that. In Go, the places where the compiler has to look are
quite limited, I think. Furthermore with the currently proposed contracts,
much the same
I think the idea we should focus on here is "The type is the contract".
Instead of specifying a contract though operations, just use concrete
types, including primitive types to specify the desired qualities of the
generic type.
Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
>
After reading his proposal, I think you should help Burak Sedar work out
his proposal in the other thread. It is conceptually a lot easier than the
idea of contracts, but likely to be more powerful even. To me it has the
ideal Go-like feel and it solves the problem with operator overloading in
After all the discussions about contracts, this is a refreshing new idea
that is conceptually far simpler.
Sure the details need to be worked out, maybe with a somewhat different
syntax, but it seems far better than the idea of contracts indeed.
A type is a "contract" in itself, and a
I kind of like this idea. Contracts seem likely to introduce all kinds of
complexity, and with a bit more explicit code, just generics without
contracts could work just fine. It's definitely the simplest implementation
of generics that could work.
--
You received this message because you are
Well, you could certainly implement min or max generically without operators in
contracts if you use a wrapper type for primitives and pointers. A bit more
verbose perhaps, but that is also how it is now.
I can only speak for myself and say that I would not be disappointed at all
with such
I agree that operators in contracts and the proposed generics don't seem to
mesh well. Your proposal would enable the use of operators in interfaces in an
easy way.
However, personally I think that perhaps we don't need operators at all.
Suppose I was to implement a generic btrie or such
linkat() and openat() are posix 2008 standard functions so I wouldn't call this
uncommon. As such they are useful to have in Go in one way or the other. The
x/unix package is fine for that, though.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
So no matter if I say yes or no, both ways are bad? I think is not a very fair
way to argue.
Anyway, with the Ruby standard you can do either. The Ruby standard defines
that there are strictly conforming Ruby processors, which implement the
standard and conforming Ruby processors which may
I understand very well what the risks of standardization can be. Look at
how the C language was maimed during standardization by 104 instances of
undefined behavior.
But that is not what I am getting at. Five years ago I was somewhat
involved in the effort to make Ruby an ISO standard language.
In certain environments, such as for government contracting in certain
countries, or for certain large corporations, or for developing safety critical
applications using certain international standards, only programming languages
that are officially standardized may be used. While Go would be
15 matches
Mail list logo
