Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Fluent Method Chaining for Status and Type Methods Using Generics #3221

Open
coderabbitai bot opened this issue Nov 29, 2024 · 11 comments · May be fixed by #3296
Open

Implement Fluent Method Chaining for Status and Type Methods Using Generics #3221

coderabbitai bot opened this issue Nov 29, 2024 · 11 comments · May be fixed by #3296
Assignees
Milestone

Comments

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 29, 2024

We propose implementing the fluent concept for the methods Status and Type in the Fiber framework using generics, as discussed in the following articles:

Background:

Using generics allows for method chaining by having methods return a generic interface type, similar to the self keyword in other languages. Since Go does not have a self keyword, generics provide a feasible alternative without significant language changes.

Proposal:

  • Modify the Context Interface:

  • Change methods like Status and Type to return a generic interface instead of a concrete type.

  • This enables fluent method chaining while maintaining type safety and flexibility.

  • Implement a Generic Ctx Interface on App:

    • To prevent class switching when registering a custom context that uses fluent methods, implement a generic interface for Ctx on the App.
  • Provide Multiple New Methods:

    • Offer additional constructor methods so developers who do not need a custom context can continue using fiber.New without any changes.
    • Provide alternative constructors for those who wish to customize the context.

Benefits:

  • Maintains ease of use for existing users.
  • Enhances flexibility for developers requiring custom contexts.
  • Utilizes Go's generics feature introduced in 1.18 for improved design patterns.

References:

Requested by: @ReneWerner87

@ReneWerner87 ReneWerner87 added this to v3 Nov 29, 2024
@ReneWerner87 ReneWerner87 added this to the v3 milestone Nov 29, 2024
@ReneWerner87 ReneWerner87 moved this to Todo in v3 Nov 29, 2024
@ReneWerner87 ReneWerner87 self-assigned this Jan 10, 2025
@rishabhDev2700
Copy link

Hi, I would like to work on this issue.

@ReneWerner87
Copy link
Member

Hi, already working on it
You are welcome to help with other issues

@rishabhDev2700
Copy link

rishabhDev2700 commented Jan 27, 2025 via email

@ReneWerner87
Copy link
Member

Will push my changes in a few hours

@ReneWerner87
Copy link
Member

@rishabhDev2700 maybe you can help us with the current status, we still have some errors and problems which we have to solve

@ReneWerner87
Copy link
Member

we still have the fluent interface method chaining problem

package main

import (
	"context"
	"fmt"
)

type Service[T any] interface {
	Execute() string
	WithContext(ctx context.Context) Service[T]
}

type MyService struct {
	ctx context.Context
}

func (m *MyService) Execute() string {
	return "Executing..."
}

func (m *MyService) Special() string {
	return "Special method"
}

func (m *MyService) WithContext(ctx context.Context) Service[*MyService] {
	m.ctx = ctx
	return m
}

func main() {
	service := &MyService{}
	fmt.Println(service.Special()) // OK

	wrapped := service.WithContext(context.Background()) // <- self reference 
	
	if typed, ok := wrapped.(*MyService); ok { // we want it without type assertion
		fmt.Println(typed.Special()) // Works with type assertion
	} else {
		fmt.Println("Type assertion failed")
	}
}

@rishabhDev2700
Copy link

@ReneWerner87 I will work on it

@ReneWerner87
Copy link
Member

But use the current code changes from the existing branch

@rishabhDev2700
Copy link

rishabhDev2700 commented Feb 10, 2025 via email

@rishabhDev2700
Copy link

@ReneWerner87 Can you please provide me some pointers on this issue.
Right now, there are issues like recursive type and redeclaration of interface/structs in ctx_custom_interface.go

@ReneWerner87
Copy link
Member

@rishabhDev2700 Right, the problem of recursive generics must be solved
And the other problems that are reported when you start the tests
Also we have to try to make the usage as easy as possible for the consumer after this change, i.e. use aliases so that you don't always have to define a type for the ctx generic
And at the end we have to document the customizations in the markdown files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

2 participants