Runtime feature mix-in pattern
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Empieza por localizar el manejo de la configuración en tiempo de ejecución y el paso de creación de objetos descritos en el issue; después, sigue la estructura de herencia de Service y Endpoint. La tarea estará terminada cuando la configuración en tiempo de ejecución pueda definir una lista ordenada de clases mix-in y el tipo del objeto creado utilice ese orden de herencia, manteniendo el comportamiento cooperativo de super().
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The number of potentially desirable features on top of the basic dripline objects (Service and Endpoint) is large and it does not really make organizational sense to put everything into a single class. In some cases, the expected behaviors may even be mutually incompatible.
Rather than trying to create some set of derived classes that implement every possible useful combination, we propose the following pattern:
- additional features are implemented as mix-in classes, each inheriting from the lowest possible base class
- method overrides should never re-implement the logic from the base class, they should use
super()to re-use that logic (but may alter the arguments passed or process the results returned as appropriate). They should also also not call the parent method directly, but should use super, so that all overrides are called in order when there is possibly multiple inheritance. - because inheritance order is unknown, every class's
__init__should be designed in such a way that being called more than once is not problematic - in runtime config, a user specifies the (ordered) list of mix in classes to be used. The user is responsible for understanding the compatibility implications and ordering of inheritance.
- at runtime, the object creation step should define a new object type with the inheritance set as defined
- Lenguaje dominante
- Python
- Estrellas
- 3
- Forks
- 6
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de driplineorg/dripline-python
-
Log on set delayAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
driplineorg/dripline-python#222 · 1 comentario ·
-
Create Logging WrapperAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
driplineorg/dripline-python#221 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 50/100
driplineorg/dripline-python#214 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
driplineorg/dripline-python#207 ·
-
Inconsistent response behavior with a 'values' arrayQuizá libre de nuevo @pkolbeck la tomó hace 498 días y no hay ningún pull request abierto. Abierto
driplineorg/dripline-python#204 · 1 comentario · 2 asignados ·
Todos los issues de driplineorg/dripline-python
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Los mantenedores suelen responder en 4 días
-
Add alembic upgrade predeployAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
ClockGU/clockwork-backend#169 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
aws-samples/sample-per-model-bedrock#616 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
chnm/teachinghistory-hugo#47 ·
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
pandas-dev/pandas-stubs#2047 · 2 comentarios ·
Los mantenedores suelen responder en 1 día