Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

NoExport by-default

Abierto
  • ¿Algo no está bien?
#151 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php
Área
compilers

Línea de trabajo

Start from the export-table generation logic and the existing attribute handling (the issue links swoole.com/aot/en/docs/no-export for current behavior). Decide how #[ExportAs] with and without a name maps onto the export table, then locate where public PHP functions/methods are collected at build time so they become excluded by default. Done looks like: a small test project where an unannotated function is absent from the export table, an #[ExportAs] function appears under its chosen name, and name-conflict errors surface clearly. Note this is a breaking-change proposal still open for maintainer decision, so confirm intent before coding.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi! First of all, thanks for such a cool project.

My suggestion is to disable all export of public PHP methods by default. The current behavior implies that a method is explicitly exported in the build unless specified otherwise: https://swoole.com/aot/en/docs/no-export

Instead, add the opposite attribute:

#[ExportAs] // "php_foo" (?) by defult
function foo(): void {}

#[ExportAs(name: 'exported_function_name')] // custom name
function foo(): void {}

Proposal Problems

    1. Changing behavior requires breaking BC
    • Counterargument: This is not critical in the current 0.x release
    • Counterargument: There have already been precedents of core's BC (behavior upon integer overflow).
    1. Name conflicts are possible (If user names are allowed).
    • Counterargument: The code's author writes this attributes, so they have control over this and can fix any name conflict errors.
    • Counterargument: In the case of conflicts with vendor code, an option could be added in the future to specify exactly which directories (or namespaces) should be considered when building the export table. For example: 
      # project.yml
export:
  - app/
  - vendor/some/any/

Winnings

    1. A more aggressive DCE could be used in the future, removing unnecessary global functions, classes, and methods from the build.
    1. Allow inlining even of public functions if the compiler deems it necessary or unless otherwise specified.
    1. Security (?): If code is distributed as part of a solution (so/dll/dylib/etc.), external software will not be able to access the internal implementation directly, since the export table is explicitly defined by the developer.
Lenguaje dominante
PHP
Estrellas
1.4k
Forks
80
Merge medio
1 d 9 h
PR fusionados (30 d)
25

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.