Case sensitive PhP scripts

View: New views

2 Messages — Rating Filter: Alert me

Case sensitive PhP scripts

by Javier de Lorenzo-Cáceres :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

This has been touched but not corrected yet and what is more important, I think it must be adviced from time to time, specially to new developers and even more if new developers are going to work in a stable edition and maybe, most probably, are not familiar with the particular issues of Turkish and other languages. We all know that PhP is not case sensitive but what is ignored is that there is a reason to treat it like if it was.

The example is the Turkish letters i and I. They are 2 different letters and there are 2 other characters, one for the uppercase of i and another for the lowercase of I.

The side effect and the actual state of WebERP is that we have a library called DateFunctions.inc where there are functions like Is_Date, see Line 19. And there are scripts like Customers.php that call this function in lowercase, see Line 100. When Turkish is selected this function will fail,

Fatal error: Call to undefined function is_date() in ... Customers.php on line 100

It will happen when Turkish is selected by the user, just because I <>uppercase(i) but other languages may have similar issues.

I believe that the same issue will occur for PhP functions like is_numeric() if we make a call using Is_Numeric.

To prevent this kind of issues and improve the WebERP multi-language feature, I think the best practice is to treat PhP as a case sensitive programming language.

We have also discussed the case style yet, being Camel Case and underscores, both intended to enhance the readability, the most prefered, and encountered the use of a mix of both styles, i.e., Is_Date, a bit redundant although it is the most readable. But being more pragmatic and a bit lazy :-) I would let a find | grep to decide, and the winner would be to use Is_Date, since it only has 10 files to change against aprox 30 for is_date.

If you think I'm being more than a bit lazy, just think this has to be done for all the functions of all libraries, at least those that have an i or and I.

If you prefer to use is_date() this is the moment to argue, for example, that it matches the php style.

Thanks,

javier

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: Case sensitive PhP scripts

by Tim Schofield :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Javier,

I agree. I have tried to remove these as I come across them but they
should be consistent. I am happy to go with whatever is the easiest.

Tim

2009/11/5 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>:

> This has been touched but not corrected yet and what is more important, I
> think it must be adviced from time to time, specially to new developers and
> even more if new developers are going to work in a stable edition and maybe,
> most probably, are not familiar with the particular issues of Turkish and
> other languages. We all know that PhP is not case sensitive but what is
> ignored is that there is a reason to treat it like if it was.
>
> The example is the Turkish letters i and I. They are 2 different letters and
> there are 2 other characters, one for the uppercase of i and another for the
> lowercase of I.
>
> The side effect and the actual state of WebERP is that we have a library
> called DateFunctions.inc where there are functions like Is_Date, see Line
> 19. And there are scripts like Customers.php that call this function in
> lowercase, see Line 100. When Turkish is selected this function will fail,
>
> Fatal error: Call to undefined function is_date() in ... Customers.php on
> line 100
> It will happen when Turkish is selected by the user, just because I
> <>uppercase(i) but other languages may have similar issues.
>
> I believe that the same issue will occur for PhP functions like is_numeric()
> if we make a call using Is_Numeric.
>
> To prevent this kind of issues and improve the WebERP multi-language
> feature, I think the best practice is to treat PhP as a case sensitive
> programming language.
>
> We have also discussed the case style yet, being Camel Case and underscores,
> both intended to enhance the readability, the most prefered, and encountered
> the use of a mix of both styles, i.e., Is_Date, a bit redundant although it
> is the most readable. But being more pragmatic and a bit lazy :-) I
> would let a find | grep to decide, and the winner would be to use Is_Date,
> since it only has 10 files to change against aprox 30 for is_date.
>
> If you think I'm being more than a bit lazy, just think this has to be done
> for all the functions of all libraries, at least those that have an i or and
> I.
>
> If you prefer to use is_date() this is the moment to argue, for example,
> that it matches the php style.
>
> Thanks,
> javier
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-erp-developers mailing list
> Web-erp-developers@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>