Refact de l'API "sys"

Autrefois, pour des raisons de naming, et afin d’éviter toute collision ou confusion avec des méthodes potentiellement injectées, nous avions été contraints de préfixer toutes les méthodes du module sys avec le symbole $.

Cependant, compte tenu de l’évolution du projet et de sa maturité actuelle, il serait pertinent de revoir cette approche. Je propose que nous réécrivions ce module en adoptant une syntaxe plus claire et plus conventionnelle, en abandonnant le préfixe $.

Une alternative envisageable serait d’utiliser une convention basée sur la capitalisation, par exemple : mettre en majuscule la première lettre de chaque méthode.

Exemple :
__sys__.Mth1

[supper-coder]

D'une part c'est supert car ça pourrait permettre de pouvoir avoir une syntaxe un peu plus propre mais comment pensons-nous aux systèmes qui utilisent déjà ces syntaxes ?

[iDevo-ll]

Je propose une refonte du module sys afin d’améliorer sa lisibilité, sa cohérence et sa scalabilité.

Aujourd’hui, le module est assez centralisé et repose sur un préfixe $ historiquement utilisé pour éviter certaines collisions. Même si ce choix était pertinent au départ, il complexifie désormais la lecture et s’éloigne des conventions standards de l’écosystème JS/TS.

Objectifs

• Clarifier les responsabilités
• Adopter des conventions de nommage standard
• Faciliter la maintenance et l’évolution du module

Nouvelle structure

• sys.os → opérations liées au système d’exploitation
• sys.fs → gestion du système de fichiers
• sys.path → manipulation des chemins
• sys.env → détection et informations d’environnement
• sys.config → gestion des variables dynamiques (remplace $get, $add, $update)

Convention de nommage

Suppression du préfixe $ au profit du camelCase, plus idiomatique en JavaScript / TypeScript.

Exemple d’utilisation

__sys__.env.isProduction()

__sys__.config.get("version")
__sys__.config.set("appName", "XyPriss")

__sys__.fs.readFile()
__sys__.path.join()

Bénéfices

• API plus lisible et intuitive
• Structure modulaire et extensible
• Alignement avec les standards de l’écosystème
• Réduction du couplage et meilleure organisation interne

Cette approche permet de faire évoluer __sys__ vers un module plus propre et plus robuste, tout en conservant sa puissance actuelle.

Je suis preneur de vos retours avant d’avancer sur une implémentation complète.

[supper-coder]

ok bien vu, je propose de changer "config" par "vars" c'est plus court et simple

[zetad2]

bah vous décidez quoi finalement ????? je suis un peu épuisé

[iDevo-ll]

ok bien vu, je propose de changer "config" par "vars" c'est plus court et simple

Yes, bien vu 👍 je suis d’accord, vars est plus court et reste suffisamment explicite dans notre contexte.

Du coup, si on récapitule la direction finale :

• __sys__.env → environnement
• __sys__.vars → variables dynamiques
• __sys__.fs → système de fichiers
• __sys__.path → gestion des chemins
• __sys__.os → système d’exploitation

Avec :

• suppression du préfixe $
• adoption du camelCase pour les méthodes

Exemple final

__sys__.env.isProduction()

__sys__.vars.get("version")
__sys__.vars.set("appName", "XyPriss")

__sys__.fs.readFile()
__sys__.path.join()
__sys__.os.platform()

[zetad2]

ok bien vu, je propose de changer "config" par "vars" c'est plus court et simple

Yes, bien vu 👍 je suis d’accord, vars est plus court et reste suffisamment explicite dans notre contexte.

Du coup, si on récapitule la direction finale :

• __sys__.env → environnement
• __sys__.vars → variables dynamiques
• __sys__.fs → système de fichiers
• __sys__.path → gestion des chemins
• __sys__.os → système d’exploitation

Avec :

• suppression du préfixe $
• adoption du camelCase pour les méthodes

Exemple final

__sys__.env.isProduction()

__sys__.vars.get("version")
__sys__.vars.set("appName", "XyPriss")

__sys__.fs.readFile()
__sys__.path.join()
__sys__.os.platform()

ok j'approuve

[supper-coder]

aussi, j'ai une question, généraleent les discussions se font en interne pourquoi sur git cette fois ??

[iDevo-ll]

Rapport de Décision : Refact de l'API "sys"

1. Problématique Initiale

L'utilisation du préfixe $ pour les méthodes du module sys (ex: __sys__.$Mth1) avait été adoptée pour éviter les collisions de nommage. Cependant, l'équipe a jugé cette syntaxe peu conventionnelle et nuisible à la lisibilité à mesure que le projet gagne en maturité.

2. Changements Adoptés

Après échanges entre NEHONIX Devs Admin, supper-coder, codeloverdev et iDevo-II, les décisions suivantes ont été actées pour améliorer la cohérence avec les standards JS/TS :

• Suppression du préfixe $ : Toutes les méthodes abandonnent le symbole dollar.
• Passage au camelCase : Adoption d'une nomenclature plus idiomatique (ex: readFile au lieu de ReadFile).
• Modularisation de __sys__ : Le module est désormais divisé en sous-espaces logiques :
  • env : Informations d'environnement.
  • vars : Gestion des variables dynamiques (remplace l'ancienne proposition config).
  • fs : Opérations sur le système de fichiers.
  • path : Gestion des chemins.
  • os : Système d'exploitation.

3. Exemple de la Nouvelle Syntaxe (Validation Finale)

L'implémentation finale ressemblera à ceci :

__sys__.env.isProduction()
__sys__.vars.get("version")
__sys__.vars.set("appName", "XyPriss")
__sys__.fs.readFile()
__sys__.path.join()
__sys__.os.platform()

4. Conclusion de la Discussion

L'équipe a validé la proposition de supper-coder d'utiliser vars au lieu de config pour plus de brièveté. La discussion s'est terminée sur une approbation générale ("ok j'approuve") pour passer à l'implémentation technique.

Bah c'est écrit par Gemini