Re: [PEPr] Changes in proposal for RFC::Package naming, file naming and directory structure RFC

Could you hold of on calling for votes - This One Class per file, is a little complex - I want to try and get some feedback from internals. The idea is that having one Class per file, makes the code easier to read in the long run. (although while in the early stages a developer may find it easier to work with multiple classes in 1 ) From what I can see, the only argument against this, is that it would invoke a performance penalty. - AFAIK this penalty would disappear when using APC or another cache (This needs checking with those who know then engine runing on high perf. sites..) Otherwise - If anyone has any other justification, for not going to One file per class, it should be known, and added to the pros/cons for 1 file per class discussion in the RFC. At the momemt it is a bit vauge about 'why' we need to accept putting non-instantated classes together.. if I print_r() a result, I still may need to work out where the source code, to a class is... Regards Alan PEPr wrote:

Tobias Schlitt (http://pear.php.net/user/toby) has edited the proposal for RFC::Package naming, file naming and directory structure RFC. Change comment: * Updated regarding comment by Alexey Borzov: File naming and structure/Exception "Either way every class that maybe be instantiated directly should reside in its own file." I suggest re-wording it as "every class that can be used separately". E.g. DB_result (from DB) or HTTP_Response (from HTTP_Request) can be instantiated directly, but it makes no sense to use them without other package's classes." The wording has changed now, but not exactly the way, Alexey proposed. I guess that fit's now. * Added notes regarding other comments. Thos will be deleted befor call-for-votes, since they do not belong to the RFC. Please re-review the package: http://pear.php.net/pepr/pepr-proposal-show.php?id=55

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com