Expected binaryheap to Pop int value when using NewWithIntComparator #177

Closed
opened 2021-12-10 13:34:04 +00:00 by srikarplus · 2 comments
srikarplus commented 2021-12-10 13:34:04 +00:00 (Migrated from github.com)

A heap created like heap := binaryheap.NewWithIntComparator() is expected to Pop int type element. Instead the method returns an interface that needs a type assertion. Is it possible to do this type assertion by the package itself as per the Comparator used.

A heap created like `heap := binaryheap.NewWithIntComparator()` is expected to `Pop` int type element. Instead the method returns an interface that needs a type assertion. Is it possible to do this type assertion by the package itself as per the Comparator used.
emirpasic commented 2022-04-12 20:09:39 +00:00 (Migrated from github.com)

At the time of creating GoDS, there were no generics (as this is the case with golang 1.18). Hence, type assertions were mandatory everywhere and are take the biggest performance hit when it comes to GoDS. There is discussion and roadmap to take GoDS to generics which would avoid type assertions everywhere in GoDS v2.

As for now, GoDS v1, works everywhere with interface{} types, hence the need to type assert. It's not the prettiest sight to see having to type assert everywhere, but it is not that bad either for now.

At the time of creating GoDS, there were no generics (as this is the case with golang 1.18). Hence, type assertions were mandatory everywhere and are take the biggest performance hit when it comes to GoDS. There is discussion and roadmap to take GoDS to generics which would avoid type assertions everywhere in GoDS v2. As for now, GoDS v1, works everywhere with `interface{}` types, hence the need to type assert. It's not the prettiest sight to see having to type assert everywhere, but it is not that bad either for now.
emirpasic commented 2022-04-12 20:09:39 +00:00 (Migrated from github.com)

At the time of creating GoDS, there were no generics (as this is the case with golang 1.18). Hence, type assertions were mandatory everywhere and are take the biggest performance hit when it comes to GoDS. There is discussion and roadmap to take GoDS to generics which would avoid type assertions everywhere in GoDS v2.

As for now, GoDS v1, works everywhere with interface{} types, hence the need to type assert. It's not the prettiest sight to see having to type assert everywhere, but it is not that bad either for now.

At the time of creating GoDS, there were no generics (as this is the case with golang 1.18). Hence, type assertions were mandatory everywhere and are take the biggest performance hit when it comes to GoDS. There is discussion and roadmap to take GoDS to generics which would avoid type assertions everywhere in GoDS v2. As for now, GoDS v1, works everywhere with `interface{}` types, hence the need to type assert. It's not the prettiest sight to see having to type assert everywhere, but it is not that bad either for now.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
golibs/gms-gods#177
No description provided.