Alternatives to `preferNullPrototype`
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- javascript
- Área
- backend-api-design
Línea de trabajo
Start with issue #24 and compare the proposed names against its stated constraints around Arrays, Objects, JSON import attributes, and allowed values. Done means the naming and scope question has a decided direction; no file or test entry point is mentioned in the payload.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
preferNullPrototype is the current key name for the following reasons:
nullPrototypewas passed over because it is only the non-Array Objects that get null prototypes; Arrays do not.nullPrototypeForObjectsor similar was passed over because Arrays technically are Objects so this still has the same problem as (1)
While advancing this proposal to Stage 2.7, I think the committee was split on (1) but generally agreed that (2) is a bit too pedantic. So we are reconsidering names that somehow mention Object -- we heard the following in committee:
nullPrototypeObjects: boolean
nullObjectPrototype: boolean
We also heard the following:
objectPrototype: null | ???
This option opens the door do doing things like objectPrototype: MyThing.prototype where MyThing is some user-defined class. This would not be possible in import attributes, assuming we add this key to JSON import attributes. It also would expand the scope of this proposal considerably. So assuming we are not going to do that, null and undefined (which would lead to the default Object.prototype) would be the only permissible values for objectPrototype.
I think my current weak preference is for nullPrototypeObjects.
- Lenguaje dominante
- HTML
- Estrellas
- 52
- Forks
- 4
- Merge medio
- 17 h 35 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la 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 tc39/proposal-json-parseimmutable
-
Add comma and comment optionsAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
tc39/proposal-json-parseimmutable#25 · 5 comentarios · 2 reacciones ·
Todos los issues de tc39/proposal-json-parseimmutable
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
yologdev/yoyo-evolve#1053 ·
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
doronz88/pymobiledevice3#2051 ·
Los mantenedores suelen responder en 1 día
-
Groc schedules with out of range values pass config validation and fail later when the scheduler is builtPosiblemente ocupada @auraseb la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
autowarefoundation/autoware_carla_scenario#342 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día