Hello everyone,
I just started learning Go, and I do realize this is not an OO language, but why not use methods instead of package functions to make things less verbose?
Compare:
foo.Contains(bar)
strings.Contains(foo, bar)
I've already seen a couple of "convenience methods" that repeat functionality of corresponding functions (like Sort() for example). Why not do the same for strings?
-Alex
--
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/groups/opt_out.
Except string is a built in type.
What makes you think that Go is not an OO language? Can you attach
code to a specific type? Of course you can.
In that vein, look at the size of the strings library. Making all that
functionality methods on the basic type would, as Andrew said,
complicate the language. Why complicate the language with such trivial
things when it can be achieved by a library, which is more
maintainable, easier to extend, and more flexible? The language is
much simpler the way things are.
These two ideas are in conflict. Part of what makes the current model
feel good is precisely that the strings package is just another
package. Magic improves disparity rather than symmetry.
There's a famous quote by Alan Kay saying "When I created
object-oriented programming, C++ is not what I had in mind."
it at least serves as good evidence that what
object-oriented means isn't as clear cut as one might wish for. It's
also a fairly uninteresting discussion as far as good programming
goes.
Not to structs. To any user defined type, eg. 'type Int int'.
And BTW, Go has full inheritance (the behavioral one). Still I don't consider inheritance a necessary thing of an OOP language.
-j
And BTW, Go has full inheritance (the behavioral one). Still I don't consider inheritance a necessary thing of an OOP language.
This may be quibbling, but I wouldn't count methods on 'string' as part of the language, rather as part of a "standard library". They could be implemented by a slightly-transformed version of strings.go where the functions were declared as methods on 'string', probably using some kind of magic package name like '__builtin' to allow the 'string' type be considered part of the package and thus eligible for method definitions.
--
You could quite easily implement this yourself, like this:
package main
import "fmt"
import "strings"
type String string
...
that would be great except that there's no way to use that type in real code without adding a blizzard of type-casts between string and MyString all over the place.
I just started learning Go, and I do realize this is not an OO language, but why not use methods instead of package functions to make things less verbose?
On May 2, 2013 12:21 PM, "Miguel Pignatelli" <eme...@gmail.com> wrote:
> I have seen this pattern many times in this list:
>
> A - Go is not an OO language
> B - Who said that?? You can... <<insert here at least one OO concept>> ... in Go!
>
> Only to say later...
>
> B - Stop trying to write <<insert any classic OO language here>> in Go!
>
> Come on!! Really???
Really. What's so strange about the observation of different OOP languages implement different OOP features?
My opinion is that OOP is code attached to a type since Borland came with the 'object' keyword in some version of theirs Pascal. Yeah, that was my first "OOP" experience.
-j
As I've mentioned before elsewhere, I'd like to better understand exactly what the problem would be with allowing functions to be defined on a struct outside of a struct package. It would be simple enough to prevent changing behavior by having the compiler enforce the simple rule that you can't override an already-defined function. It would allow result in cleaner-reading code and would provide more type safety (type enforced at the compiler level rather at runtime with casting). I fail to see how it would complicate the language or make reading code more difficult.
I'm not a compiler guy, so there may be some technical challenge that makes package extension difficult or computationally complex in the compiler; so far I haven't seen any argument other than the "programmers are stupid" one for the rule preventing foreign package type extension.
If you're just waxing philosophical now and not actually interested in a practical solution, my apologies for interjecting. :)
that would be great except that there's no way to use that type in real code without adding a blizzard of type-casts between string and MyString all over the place.
On Thursday, May 2, 2013, Sean Russell wrote:
As I've mentioned before elsewhere, I'd like to better understand exactly what the problem would be with allowing functions to be
The problem is coherence. Let's say two different packages define a method Foo on a type T, then someone else needs to import both packages. Which Foo do you use? Which Foos do the two packages see? What about when one of the packages puts a T in an interface and returns it to you? What about when you pass it into the other package? What about when they convert the interface to a different interface type? Frankly, it gets really messy since you're basically creating a global namespace, which defeats the purpose of the package system and creates major scalability issues.
He's talking about unexported methods. It's already possible for a type to have multipe unexported methods with the same name, each visible only in the package that defines the method and in assignments to interfaces defined in that package (via embedding).
On Sunday, May 5, 2013, Ian Lance Taylor wrote:On Sun, May 5, 2013 at 7:33 PM, Sean Russell <seaner...@gmail.com> wrote:
>
> These are all good questions. The current rule is that no functions on types
> are allowed to be defined outside of the package in which the type is
> defined, yes? What if the rule were that only package-local functions were
> allowed to be defined? None of the questions you raise above would be
> relevant any longer, would they? foo() called from the package is always the
> foo() defined in that package.
It's not that simple. What if I pass the object to a function from
some other package, a function that takes a value of some interface
type? What if multiple packages define a method String on the type T,
and one of those packages, or some other package, passes a value of
type T to fmt.Print? Which String method should be called? What if
package A defines String, passes a value of type T to package B, and
package B also defines String, and package B passes the value to
package C, and package C calls fmt.Print? Which String should be
called?
IanHe's talking about unexported methods. It's already possible for a type to have multipe unexported methods with the same name, each visible only in the package that defines the method and in assignments to interfaces defined in that package (via embedding).
On Sunday, May 5, 2013 11:50:02 PM UTC-4, Steven Blenkinsop wrote:
He's talking about unexported methods. It's already possible for a type to have multipe unexported methods with the same name, each visible only in the package that defines the method and in assignments to interfaces defined in that package (via embedding).
That's not my understanding of the language spec. The Method Set section[1] says: "In a method set, each method must have a unique method name."
What are you talking about? Each type is unique to its own package. If type Bar exists in packages foo1 and foo2, and both packages define a method on Bar called Baz() that doesnt mean they are the same types when imported to your pkg. One type is foo1.Bar and the other type is foo2.Bar.
Are you sure that unexported methods are promoted across package boundaries? Wouldn't the method set of the embedding type only contain the exported methods of types it embeds from other packages?