3 ms·

First, why is this framework using __autoload? spl_register_autoloader should be used here. Otherwise, other frameworks (like doctrine, zend, etc) can't registe

by ryeguy 16y ago

First, why is this framework using __autoload? spl_register_autoloader should be used here. Otherwise, other frameworks (like doctrine, zend, etc) can't register their autoloaders. Second, why require 5.3 and not use namespaces? Should be e.g. Eddy\Controller instead of EddyController. Third, why so many global functions? Pretty much all of these would be better suited as static functions on a class. Lastly, why use mysqli? Now whoever uses this has to use mysql. It easily could have been made to use PDO, and should have. There is no reason to use mysqli. Sorry for the criticism, but there are so many of these out there that new ones pretty much have to be flawless to even matter. This framework just seems to be made by someone who doesn't pay any attention to how other major frameworks and the rest of the community are doing things.

st0p 16y ago
Even though I agree with point 1, 2 and 4, I'm not with you on point 3. Why take OO to an extreme when there is no technical nor functional reason to do so? The best example is Math.Sin(x) vs. Sin(x)... There is no valid reason (IMHO) to go for the Math.Sin() approach in PHP. It doesn't add anything, except more keystrokes. Of course if your language is entirely OO (like C# or Java), you can't avoid constructs like Math.Sin(). Even though I prefer C# and Java above PHP, it has always annoyed me that I needed to prefix those kind of functions with a class name. I understand that it is a trade off in language design and forcing you to think in objects is mostly a good thing (if you leave functional programming out of the equation). However, if your language supports functions outside of objects, why not use them? [disclaimer]I didn't look at the actual code, so I'm not sure if there are functions that indeed should have been (static) members of a class.[/disclaimer]
simonhamp 16y ago
1. It's not meant to be used with other frameworks :) 2. Namespaces are nonsense in 5.3. I've created my own way of namespacing which is much nicer in my opinion 3. The global functions are being worked through: it's early days... less of those to come 4. MySQLi because that's what I use. Limits my support costs As with any open source framework, you can actually change it to suit your needs. It's not for everyone, if you want those things go elsewhere. This is what I use to get my apps started - they start quicker, finish sooner, work faster. It's not an exercise in 'best practice', it's about getting the job done - actually building an app that works!

by ryeguy 16y ago

st0p 16y ago

Even though I agree with point 1, 2 and 4, I'm not with you on point 3. Why take OO to an extreme when there is no technical nor functional reason to do so? The best example is Math.Sin(x) vs. Sin(x)... There is no valid reason (IMHO) to go for the Math.Sin() approach in PHP. It doesn't add anything, except more keystrokes. Of course if your language is entirely OO (like C# or Java), you can't avoid constructs like Math.Sin(). Even though I prefer C# and Java above PHP, it has always annoyed me that I needed to prefix those kind of functions with a class name. I understand that it is a trade off in language design and forcing you to think in objects is mostly a good thing (if you leave functional programming out of the equation). However, if your language supports functions outside of objects, why not use them? [disclaimer]I didn't look at the actual code, so I'm not sure if there are functions that indeed should have been (static) members of a class.[/disclaimer]

simonhamp 16y ago

1. It's not meant to be used with other frameworks :) 2. Namespaces are nonsense in 5.3. I've created my own way of namespacing which is much nicer in my opinion 3. The global functions are being worked through: it's early days... less of those to come 4. MySQLi because that's what I use. Limits my support costs As with any open source framework, you can actually change it to suit your needs. It's not for everyone, if you want those things go elsewhere. This is what I use to get my apps started - they start quicker, finish sooner, work faster. It's not an exercise in 'best practice', it's about getting the job done - actually building an app that works!