KCL语言JSON Schema导入时的属性命名转换问题分析

在KCL语言工具链中，存在一个关于JSON Schema导入功能的属性命名转换问题。当开发者使用kcl import命令将JSON Schema转换为KCL Schema时，所有属性名都会被自动转换为蛇形命名法(snake case)，而不管原始JSON Schema中使用的是什么命名规范。

问题现象

当开发者导入一个包含驼峰命名法(camelCase)属性的JSON Schema文件时，例如：

{
  "properties": {
    "firstName": {
      "type": "string"
    },
    "lastName": {
      "type": "string"
    }
  }
}

转换后的KCL Schema会将属性名强制转换为蛇形命名法：

schema PersonSchema:
    first_name?: str
    last_name?: str

这种自动转换行为可能会导致以下问题：

1. 与原始JSON Schema的命名规范不一致
2. 与后端API或其他系统交互时出现命名不匹配
3. 需要额外的映射工作来保持一致性

技术背景

在JSON Schema和KCL Schema的转换过程中，命名规范的自动转换通常是为了保持代码风格的一致性。许多编程语言社区对变量命名有特定的偏好：

• Python社区倾向于使用蛇形命名法
• JavaScript/TypeScript社区倾向于使用驼峰命名法
• Rust社区也倾向于使用蛇形命名法

KCL作为一种配置语言，其工具链可能默认采用了类似Python的命名风格。然而，这种强制转换并不总是符合用户预期，特别是当JSON Schema需要与使用不同命名规范的系统保持一致性时。

解决方案建议

理想的解决方案应该提供以下功能：

1. 保留原始命名：默认情况下不应自动转换属性名，保持与JSON Schema一致
2. 提供转换选项：通过命令行参数支持不同的命名规范转换
   • --snake：转换为蛇形命名法(first_name)
   • --camel：转换为驼峰命名法(firstName)
   • --pascal：转换为帕斯卡命名法(FirstName)
3. 智能识别：可以添加启发式规则，当检测到混合命名时给出警告

实现上，可以在kcl import命令中添加新的可选参数来控制命名转换行为，同时修改生成器代码，使其在无明确指令时保持原始命名不变。

影响评估

这个问题的修复将带来以下好处：

1. 提高工具链的灵活性，适应不同命名规范的JSON Schema
2. 减少开发者在不同命名规范间手动转换的工作量
3. 保持与现有系统的更好兼容性
4. 提供更符合用户预期的默认行为

对于已经依赖当前行为的用户，可以通过显式指定--snake参数来保持原有功能，确保向后兼容。

总结

KCL语言的JSON Schema导入功能应该尊重原始Schema的命名规范，而不是强制进行命名转换。通过添加可选参数来控制命名转换行为，可以在保持现有功能的同时提供更大的灵活性。这种改进将使KCL工具链更加完善，更好地服务于多样化的开发场景。