Static methods
Nihlus
methods which would be called like T.some_fun(...) for a type T? This
would offer a degree of function overloading capability enabling the
users to define their own functions like for example T.new().
Ryanne Dolan
Nihlus
as a syntactic sugar for zero.some_fun() where zero is the zero value
for type T. Thus some_fun() would be implemented as an ordinary method
for the type (with the value of the receiver simply discarded) and
would belong to the method set of T. The syntax T.some_fun() would
relieve us from the necessity of creating a meaningless variable just
to call some_fun(). It would be similar in essence to the comma, ok
syntax for map queries.
>
> - Pokaż cytowany tekst -
yy
> some_fun() would be implemented as an ordinary method
> for the type (with the value of the receiver simply discarded)
Why having a receiver if you are going to discard it? What would be
the advantage of using a T.New() method instead of a NewT() function?
--
- yiyus || JGL .
Evan Shaw
> I think it could be a good idea to introduce the syntax T.some_fun()
> as a syntactic sugar for zero.some_fun() where zero is the zero value
> for type T. Thus some_fun() would be implemented as an ordinary method
> for the type (with the value of the receiver simply discarded) and
> would belong to the method set of T. The syntax T.some_fun() would
> relieve us from the necessity of creating a meaningless variable just
> to call some_fun(). It would be similar in essence to the comma, ok
> syntax for map queries.
I don't get the value here. My thoughts are:
- If some_fun only needs a "meaningless variable" of type T, then why
is it a method on T in the first place? Why not just remove that
parameter and make it a normal function?
- This is really asking a lot of the compiler. Consider:
func Foo(t T) {
t.some_fun()
}
How can the compiler to statically know whether t contains the zero value for T?
- Evan
Rob 'Commander' Pike
Don't get me wrong. Methods are a brilliant invention that Go exploits to its great benefit. But the same sentence applies with "functions" as the first word.
A static method is not a method, it is an OOO misnomer from a confused age. It is just a function. And look! Go has functions. Problem solved. Nomenclature rebuffed.
-rob
Chip Camden
Agreed.
A method is a function with a special convention for its arguments.
--
Sterling (Chip) Camden | ster...@camdensoftware.com | 2048D/3A978E4F
http://chipsquips.com | http://camdensoftware.com | http://chipstips.com
Nihlus
> as a syntactic sugar for zero.some_fun() where zero is the zero value
> for type T.
clarify some Go's concepts. Perhaps things would be clearer if "new"
were called "ini" because all it really does in Go is to supply a zero
value for value-types without declaring a named variable.
Nihlus
be complemented with an "ini" function returning just the zero value?
The advantage of "ini" would be that it would not put a burden on GC.
jimmy frasche
Nihlus
T) but you could write ini(T).some_fun() or some_fun(ini(T)) of if x
== ini(T) {...} etc.
On 2 Mar, 09:17, jimmy frasche <soapboxcic...@gmail.com> wrote:
> var z T creates z as a zero-value of type T already
>
roger peppe
> Except that you cannot write (var z T).some_fun(), nor some_fun(var z
> T) but you could write ini(T).some_fun() or some_fun(ini(T)) of if x
> == ini(T) {...} etc.
for types that allow being passed by value, there's always a zero
value expression.
for structs it's T{}
e.g. T{}.some_fun().
for non-structs, it's a type conversion from the literal,
e.g. os.Errno(5).String()
Nihlus
[100]int?
On 2 Mar, 09:49, roger peppe <rogpe...@gmail.com> wrote:
roger peppe
> How about arrays? For example, what is the zero value expression for
> [100]int?
the same as for structs.
e.g.
type T [100]int
func (t T) some_fun() { }
T{}.some_fun()
Nihlus
"If fewer elements than the length are provided in the literal, the
missing elements are set to the zero value for the array element type"
so we can write buf := [100]int{}
⚛
> I think it could be a good idea to introduce the syntax T.some_fun()
> as a syntactic sugar for zero.some_fun() where zero is the zero value
> for type T.
helpful to you:
The proposed language feature is one of the worst ideas I have seen in
a while. It does not make any sense from a performance perspective,
and you want the Go's primitive "function call" to create new data,
and not to mention that the syntax conflicts with the already existing
syntax of the Go language. It is - by a large margin - worse than the
idea of allowing any pointer in a programming language to be 'nil'.
But if you have *evidence* that it would be *useful* in *actual*
programs, go ahead and persuade me that I am in error.
Andrew Gerrand
I doubt I'm alone in regarding the tone of this email as unnecessarily
combative. You raise some valid points but they are clouded by
negativity. Your message would be more constructive without the
vitriol:
`
Your proposal raises questions about performance, in that you want the
primitive "function call" to create new data. Also, the syntax
conflicts with existing syntax of the Go language. This seems more
dangerous than the controversial idea of allowing any pointer in a
programming language to be 'nil'.
However, I am open to being persuaded otherwise.
`
I apologize for calling ⚛ out in particular, but I think the general
level of civility in golang-nuts should be raised.
Andrew
⚛
of cause-and-effect. If someone feels that society *in general* (i.e:
outside of golang-nuts) is not being nice to him/her, it is only
*logical* to return the "favor" in some form. Until the cause is
removed, it is irrational to behave differently. Sorry, but that is
the plain truth here.
roger peppe
> I think you don't recognize the cause of the behavior. It is a matter
> of cause-and-effect. If someone feels that society *in general* (i.e:
> outside of golang-nuts) is not being nice to him/her, it is only
> *logical* to return the "favor" in some form. Until the cause is
> removed, it is irrational to behave differently. Sorry, but that is
> the plain truth here.
i think you're saying that because you're unhappy, you're
just going to splatter golang-nuts with the resulting bile
and you think that's ok.
that's a very sad attitude.
cheer up!
Mike Ramirez
On Thursday, March 03, 2011 12:28:51 am ⚛ wrote:
> I think you don't recognize the cause of the behavior. It is a matter
> of cause-and-effect. If someone feels that society *in general* (i.e:
> outside of golang-nuts) is not being nice to him/her, it is only
> *logical* to return the "favor" in some form. Until the cause is
> removed, it is irrational to behave differently. Sorry, but that is
> the plain truth here.
I disagree with this being the *logical* solution. It is reaction from a certain point of view, one that isn't disposed to letting people be who they are. There is such a thing as ignore it and go on with buisness, let the distractions go.
If you feel challenged or disrespected, in this case, the only challenge that matters is one where your life is at stake (or you're physically challenged). Last time I checked no one actually hit or killed anyone throwing a few words around on a mailing list (in a bar is another matter). Really how important are insults and/or comments that appear to be insulting, to let it bother you?
Overall for the look and feel of golang-nuts, Andrew has a point. I haven't really noticed it, but I also tend to gloss over those parts and try to extract the important information. In *'s original post, before Andrew pointed it out, I didn't notice it, but I was not looking for it. There is a point where the reader needs to take responsibility in terms of ignoring the ego's and antagonistic remarks. .
My less than two cents.
Mike
--
This generation doesn't have emotional baggage. We have emotional moving vans.
-- Bruce Feirstein
ger...@cloudoki.com
Marvin Renich
> I'm not sure about its *idiomacity*, but namespacing should be a nice thing.
> On Tuesday, March 1, 2011 at 8:48:52 PM UTC, yiyus wrote:
Do you realize you are responding to an eight-year-old thread? If you
really feel a need to reopen an old thread, please preface your message
appropriately, so that it's obvious.
In this case, I suspect many people on this list will disagree with your
reasoning. There will only be one type T in the package, and therefore
func NewT() will already be unique in the package namespace.
...Marvin
ger...@cloudoki.com
Marvin Renich
aggressive. That was definitely not my intention. My state of mind
when I wrote it was conversational, not antagonistic, and I did not
realize you would interpret it any other way.
* ger...@cloudoki.com <ger...@cloudoki.com> [191018 11:08]:
>
> Actually I haven't noticed it was a 8 year old thread, neither had I
> noticed that there should be any kind of preface in such cases (well, it
> was just a comment and the group rules are not that clear, afterall).
how a mailing list or online discussion group works, you have many (in
this case presumably thousands of) readers who are reading the posts
chronologically as they are posted. They have, typically, shorter
memory for details and longer memory for general trends. When you post
a reply to a thread that died years ago, it is helpful to give these
thousands of readers a clue that they will have to go back to the
archives to figure out what the thread was about.
My intent was to be instructional, not critical. Again, if you felt I
was criticizing you, please accept my apologies.
> My
> comment was about a rather *usual feature in OOP languages and that people
language. When people new to Go post on this list with OO
preconceptions about writing code in Go, they are frequently given the
suggestion to rethink the structure of their program using Go concepts,
rather than trying to shoe-horn the Go language to OO concepts.
> About *the subject*: I agree with you that the convention T/NewT is
> functions that should me modelled as static methods in other languages) it
> might clog the package namespace. That might lead programmers unexperienced
that trying to use Go packages as OO classes will generally lead to less
robust and less idiomatic Go code. I'm not sure I understand which side
you are on about NewT vs. T.New, but even in large packages with many
types, I don't think that using NewT will clog the namespace any more
than T.New will.
> About *your message*: I believe that most people might disagree with static
> methods in GO (*maybe me included*), some might not, but anyways I believe
> you?
opinion based on experience) "many" (not all) will disagree. This
opinion was based on what has been written by others on this list over
the many years that I have read and participated in discussions here.
> And, moreover, I do not think the aggressive tone on your message is
Again, I apologize if I sounded aggressive. In a written medium, it is
difficult to convey tone. If you were to take a heated verbal technical
discussion between two close colleagues and transcribe it, a third party
reading it my very well get the impression that the two were bitter
enemies.
...Marvin