Sometimes us programmers not on the CakePHP development team will think that we have an improvement to the core code, so we come up with our own solution (hack) to "improve" things. But then inevitably the core code gets changed, and we suddenly find out that our hack is broken, or just didn't make sense in the context of the future direction of the Cake core.
This is why I think it might be hazardous to not use strict. Presumably certain rules are in place, because the people who live and breath the PHP core code have a good idea about where things are going and they are trying to signal to us how to do things properly so that they match where they are going and don't break with future versions. On Jun 7, 10:26 am, Gwoo <[EMAIL PROTECTED]> wrote: > The blank check metaphor is excellent. It can be a very slippery slope > when heading down the path of non-strict compliance. If we understand > the hazards and take precautions hopefully we can prevent sliding down > too far. > > As far as what Nate is getting at, I think I understand him correctly > when I say that the need to move outside of strict mode comes with the > Models. Basically, if we do not comply with strict mode, we can call > models statically, with late bindings and without the need for a > separate Record class for handling data results as objects. > > To put it in code, and based on some initial testing we should be able > to do: > $post = Post::create(); > $post->title = "This is cool"; > Post::save(); > > This violates strict mode because you are calling static methods on a > non static class. > Anyway, this is the best I can do to explain the scenario we have > encountered so far. Bottom line is..we do want the best framework. To > us, that means code that is cleaner and simpler. Sometimes the > benefits of such ease outweigh the costs of being completely > compliant. To be honest, I do not know 100% the inner workings of php. > My fear is that php could change and we would end up with unexpected > behavior. Also, while I do not support labels, being strict means > being "enterprise" ready. For the average developer this is not a > problem, but for larger companies looking to adopt Cake this is a > valid concern for the same reasons as the slippery slope. > > There are more questions...How important is static access to models? > Should we just create instances as we do now? Would you prefer the > global access that a static class would provide? > > Hope this helps the discussion. I look forward to more opinions on how > people see the use of CakePHP evolving. > > Bake on. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
