Oh, I'd like to add that I have full trust and faith in the developers of the CakePHP project and any decisions made regardless of any possible suggestions offered by others, I simply feel that the general base of readers of this mailing list might not be able to offer a huge insight whereas others known within PHP itself may be a better group to ask such a general (or specific) question. Good luck in the decision making process for 2.0!
On Jun 9, 3:41 pm, BrendonKoz <[EMAIL PROTECTED]> wrote: > I would vote for contacting some higher level PHP enthusiasts and see > if they could offer some insight. I'd imagine that certain areas of > strictness can cause slowness, and may be going *way* out of the way > for the sake of being strict, whereas other areas may benefit highly > to keep things strict. I'd think security, forward compatibility and > efficiency (of code and resources) would be priorities (not in any > specific order). Therefore, Chris Schifflet, OmniTI, and perhaps Ilia > Alshanetsky would be some contacts that would give some greater > insight in to what may be acceptable losses and/or gains for the > project. > > On Jun 9, 9:09 am, mbavio <[EMAIL PROTECTED]> wrote: > > > > > Another vote for strict. > > > Cheers, > > mbavio > > > On Jun 9, 9:18 am, Sliv <[EMAIL PROTECTED]> wrote: > > > > Personally, I think it's best to pick standards up-front to abide by > > > for anything your code taps into and then commit yourself to > > > conforming to those documented standards...If you're using PHP, make > > > sure you pass E_STRICT tests and that's where it ends. If you're > > > using html, pick a strict doctype and commit to making sure you always > > > pass validation for that specification. Same for RSS, XML, etc. > > > > What I like about this approach is that you can say right up front, > > > here are the standards we're conforming to for all the technologies we > > > use. The goal is then not to meet the requirements of browsers, > > > readers, clients, etc., but to meet the requirements of those > > > standards. I think it makes it an attainable goal, makes it clear for > > > developers using the framework to know what they're dealing with and > > > gives an easy, clear answer to all the "what about x browser's bug, > > > what about php scenario x with library y, what about reader a and > > > client b, why don't you write code like abc, blah, blah"- Hide quoted > > > text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
