命名空间与$imported

DeathKing

在之前的FSL策略中，是将模块嵌套的：

1. module FSL
   
2.   module Conf
   
3.     module A_Game
   
4.     end
   
5.   end
   
6. end

复制代码

沉影前辈提出了宝贵的意见，说可以取消嵌套，想了一下，可以把第一层修改为FSLConf或者直接采用FSL。就像下面这样：

1. module FSL
   
2.   module A_Game
   
3.   end
   
4. end

复制代码

这样看起来就会简洁得多，而且因为在使用这些模块的时候是用的include混成进去的，所以要修改的地方并不是很多。（保留FSL只是出于形式上的考虑，同时也意味着可以存在与非FSL脚本相同的脚本名）。

关于$imported变量的问题，我也一直拿不定主意，$imported和$fscript各有千秋，$fscript可以检查版本，但在实际用途中目前还没用到过。

有很多脚本使用了$imported，我们是因该随大流，还是标新立异？

DeathKing

回复 沉影不器 的帖子

打错了，代表脚本名称。
不一定要和每个脚本兼容，只要是需要兼容的才这样做。
   

不如归去

即使常量、方法被明文标记出来，但是无法了解这个脚本的架构、它做了什么，对于整合又有什么意义？
无论使用哪一条都已经背离了“自由、简易”的第一原则，请问这样嵌套的两级甚至三级以上的模块何处体现“简易”？

紫苏

module FSL
  module A_Game
  end
end
这个可行

$fscript 提供的功能是 $imported 的超集，目前由于 FSL 的脚本还没多少（自然也没有多少版本的更新），看不到实际效果，不妨等 FSL 推广后实际产生冲突时再看是否有保留价值

小幽的马甲

理论上$fscript可以实现并扩展$imported的所有功能，但我觉得$fscript不利于在总体上的维护，某个脚本的一次升级可能导致所有与之冲突的脚本的更新。虽然$imported也有类似问题不过似乎轻微些？
我认为如果用$imported的时候最好声明：“本脚本兼容1.X版的XXX脚本，如果发现XXX脚本版本不对请更换”之类的……
顺便，我觉得FSL更需要一个统一的文档，记录已经发布的FSL脚本中哪些脚本的哪些方法可能导致冲突

六祈

回复 DeathKing 的帖子
module的嵌套关键还是看第二层是否有用，是否有config
而FSL愚者认为还是有用的，将相关的模块都包围住，在编程中需要反射判定时会很容易。

至于$imported和$fscript，因为具体没用过，也不好说，但统一的编程习惯能减少程序员间的改造或重用时的劳动量，而遵循前人的统一规范总是一种美德