[go-nuts] Sharing similar Interfaces across packages
The sort.Interface is designed to operate on an indexed collection.
Certain data structures may not be indexed (ex. linked list) nor do some
algorithms need to expose that they are.
Lets say I have one package with the following interface.
package One
type Item interface {
Less(item Item) bool
}
If say *for some reason* it made sense to want to use package One's Item in
package Two, but package Two already had an Item interface declared.
I would need to first import package One and explicitly prefix all uses of
Item to differentiate between the packages.
package Two
import "path/to/package/One" // ignoring the use of '.' notation to import
package block
// lets say this package has its own Item declared
type Item interface {
Len() int
Less(item Item) bool
Swap(item Item)
}
// lets also assume that Two.Item would not be appropriate for this function
func SomeOperation(a,b One.Item) bool {
...
}
Furthermore the concrete Item will need to cast/assert the type for the
passed in argument.
package Two
import "path/to/package/One"
type TwoItem int
func (this TwoItem) Less(item One.Item) {
return this < item.(TwoItem)
}
Is there a cleaner more elegant way to setup *this given* relationship? One
maybe that isn't as verbose (ex. share a single interface) and avoid the
casting?
I presume, that the proper convention would be to not share the interface
but I want to get an idea of other patterns that could be applied here.
--
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: Sharing similar Interfaces across packages
Wouldn't then the argument being passed into Less(Item) and Swap(Item) be
for two different Items?
One.Item for Less() and Two.Item for Swap().
On Saturday, September 24, 2016 at 10:31:56 PM UTC-7, Tamás Gulácsi wrote:
>
> You can embed the interface in two.Item:
> type Item interface {
> one.Item
> Len() int
> Swap(item Item)
> }
--
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: Sharing similar Interfaces across packages
Wouldn't then the argument being passed into Less(Item) and Swap(Item) be
for two different interfaces?
One.Item for Less() and Two.Item for Swap().
On Saturday, September 24, 2016 at 10:31:56 PM UTC-7, Tamás Gulácsi wrote:
>
> You can embed the interface in two.Item:
> type Item interface {
> one.Item
> Len() int
> Swap(item Item)
> }
--
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: Sharing similar Interfaces across packages
The interface for One.Item is expecting a One.Item as an argument to its
Less() method.
By embedding it in Two.Item, that shouldn't change that correct?
So the resulting public interface for Two.Item *after embedding* One.Item
is technically.
type Item interface {
Less(One.Item) bool
Len() int
Swap(Two.Item)
}
But I see what you mean given the example, that would be appropriate for
SomeOperation(One.Item).
On Sunday, September 25, 2016 at 12:10:37 AM UTC-7, Tamás Gulácsi wrote:
>
> An interface is not a class, but the contract of minimal provided methods:
> as Two has more methods, anything implements a two.Item will also implement
> one.Item.
--
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: Sharing similar Interfaces across packages
But unfortunately that would mean changing the public interface of
Two.Item. Which is not desired (but that wasn't specified explicitly in the
example given).
On Sunday, September 25, 2016 at 3:22:57 AM UTC-7, question@gmail.com
wrote:
>
> The interface for One.Item is expecting a One.Item as an argument to its
> Less() method.
> By embedding it in Two.Item, that shouldn't change that correct?
>
> So the resulting public interface for Two.Item *after embedding* One.Item
> is technically.
>
> type Item interface {
> Less(One.Item) bool
> Len() int
> Swap(Two.Item)
> }
>
> But I see what you mean given the example, that would be appropriate for
> SomeOperation(One.Item).
>
>
>
>
> On Sunday, September 25, 2016 at 12:10:37 AM UTC-7, Tamás Gulácsi wrote:
>>
>> An interface is not a class, but the contract of minimal provided
>> methods: as Two has more methods, anything implements a two.Item will also
>> implement one.Item.
>
>
--
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] A more elegant way to store references with a slice?
To keep a reference to a set of objects in a slice, must it be of type []*T ? Is there a more elegant way to handle the following example? https://play.golang.org/p/73lfAntNzb tryref.id is an immutable value type and try.others is a reference type correct? can you explain why the id is copied properly but the reference to the object as well as tryref.others are not? I assume its because golang is pass by value and the type of tryref.others is not a pointer so when appending an object it creates a new instance. -- 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: A more elegant way to store references with a slice?
Thanks for the reply, I should've put "reference type" in quotes. The intention of the post was to get another's perspective to any better method to accomplish the example, which is to use a slice as a container of objects. Is there any other way besides how I implemented it? Also I understand that everything is pass-by-value, but what exactly is getting passed for tryref that retains the id but not the slice of pointers? On Sunday, November 13, 2016 at 1:03:55 AM UTC-8, Volker Dobler wrote: > > Go has no notion of "reference type". And pointer types are just > that pointers. Never think about pointer types as reference types. > There are values and pointers to values. > Slices are a bit complicated: Please read > https://blog.golang.org/go-slices-usage-and-internals > carefully. It explains everything you need to know better > than I could do here. > > V. > > Am Sonntag, 13. November 2016 05:52:49 UTC+1 schrieb > question@gmail.com: >> >> To keep a reference to a set of objects in a slice, must it be of type >> []*T ? >> >> Is there a more elegant way to handle the following example? >> >> https://play.golang.org/p/73lfAntNzb >> >> tryref.id is an immutable value type and try.others is a reference type >> correct? can you explain why the id is copied properly but the reference to >> the object as well as tryref.others are not? >> >> I assume its because golang is pass by value and the type of >> tryref.others is not a pointer so when appending an object it creates a new >> instance. >> >> -- 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.
