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
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
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.Ite
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
Le
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 {
>
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 {
>
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)