Say I want to use use a widget in a view thus:
<?php
$this->widget('MyWidget');And the definition is quite conventional:
<?php
class MyWidget extends CWidget {
…
}If I save that class in a file called Mywidget.php then the widget works if it is on NTFS, FAT32 or (normal) HFS+.
Now I deploy on FreeBSD or Lunix or something with a case sensitive(CS) FS and my application is broken.
I regard this as a bug because the inconsistent case sensitivity is (I have observed hanging out on Freenode#yii) often not expected by the user and it is not documented in the Yii Class Ref. or Def. Guide.
It is not expected by the user because 1) spl_autoload is case insensitive (CI) regardless of FS and users bring that experience to Yii; 2) the new Yii user's experience developing on Windows or Mac is of a consistently CI autoloader throughout her learning, application development phase and quite possibly during test too. Deployment is not the best time to learn this crucial lesson.
After the second time I fell foul to this, I spent some time studying Yii's autoloader and decided that I cannot easily make a fix or workaround for myself. The least bad solution for me was to set up a partition or disk image with a CS FS and put my Yii projects on that.
So I think the question here is: Should Yii simply expect users to use a CS FS in dev or find some other SQA process to eliminate such case typos? If so, how do they learn that they need to? If not, a change in Yii is needed.
I don't know what to suggest for Yii's autoloader. I think it would be good for Yii and its users if its default autoloader were either CI or CS regardless of FS. But I don't know if that would be a breaking change for existing Yii apps.
Alternatively, Yii could perhaps be configured to throw an exception in a CI environment upon detecting a case mismatch. If this were the default when YII_DEBUG is true, that would help users learn that they need to find some way to ensure that case mismatches are not present in their code.