Welcome Guest, Not a member yet? Register   Sign In
Reactor Engineers
#71

[eluser]Basketcasesoftware[/eluser]
I tend to agree somewhat. If your host isn't upgrading find another host. PHP upgrades are free. And as far as I know most development platforms (XAMPP, LAMP, WAMP, etc.) are kept current. Actually the problem is having to learn the new features of the upgrades. PHP upgrades pretty regularly. CI needs a target level to build on or they'll never catch up. According to Phil Sturgeon in this very thread Type Hinting is supposed to be dropped in 5.4 even though it's been kept in PHP since 5.0 The CI developers were even planning on it apparently and then... surprise!
#72

[eluser]moodh[/eluser]
Upgrading to 5.3 on huge live sites isn't something you do lightly, it requires heavy testing and often downtime, we waited until last week to upgrade a huge community to 5.3 as there was little gain in doing so, personally I'm glad CI is 5+, but not 5.3+.
#73

[eluser]Basketcasesoftware[/eluser]
True enough. If you happen to have some backup servers to re-route traffic to until the upgraded one is online (which thankfully my host does) it's a little easier. There are other systems which allow incremental upgrades in a more granular method, but those systems aren't cheap. I've heard horror stories about server farms on just cooling issues alone. MySpace was constantly having those issues through its hosts and Facebook has been rumored to have been having the same headaches. I don't envy those people running those host systems at all. No sir.
#74

[eluser]JasonS[/eluser]
[quote author="narcisha" date="1297865383"]Upgrading to 5.3 on huge live sites isn't something you do lightly, it requires heavy testing and often downtime, we waited until last week to upgrade a huge community to 5.3 as there was little gain in doing so, personally I'm glad CI is 5+, but not 5.3+.[/quote]

That is assuming that everyone would upgrade their application overnight. I stick with the same version of CI from the start of the project till the project goes live. CI only gets upgraded if there are bug fixes.

Rewriting an application for the next major version of CI is nonsense unless the application is due a rewrite.

EDIT: Back to my original point, I am not saying CI should go straight to PHP5.3... I just think it needs to have a good reason why it shouldn't.
#75

[eluser]moodh[/eluser]
[quote author="JasonS" date="1297870101"][quote author="narcisha" date="1297865383"]Upgrading to 5.3 on huge live sites isn't something you do lightly, it requires heavy testing and often downtime, we waited until last week to upgrade a huge community to 5.3 as there was little gain in doing so, personally I'm glad CI is 5+, but not 5.3+.[/quote]

That is assuming that everyone would upgrade their application overnight. I stick with the same version of CI from the start of the project till the project goes live. CI only gets upgraded if there are bug fixes.

Rewriting an application for the next major version of CI is nonsense unless the application is due a rewrite.

EDIT: Back to my original point, I am not saying CI should go straight to PHP5.3... I just think it needs to have a good reason why it shouldn't.[/quote]

The codebase version is not a problem, thats just another development environment and vhosting to it. Upgrading from 1.7.3 to 2.0.0 was a breeze in a couple of hours (again, huge site, old code emulated).
The problem is PHP5.2.x to 5.3.x which means a completly different server or overnight downtime, both is not very attractive solutions. Smile

My point is, upgrading PHP versions on huge sites isn't something you do lightly (you SHOULD do it though as 5.3.x is reeeeally sweet)
#76

[eluser]Phil Sturgeon[/eluser]
It has a simple reason for not using PHP 5.3, portability.

CodeIgniter strives to be portable and work on as many servers as possible. As such, 5.1.6 is the most logical, which was picked by Pascal Kriete due to Red Hat issues with the 5.2 package if I remember rightly. As soon as 5.2 becomes more viable we will use it and in time, 5.3.

PHP have suggested that hosting providers and sys admins start upgrading to PHP 5.3 now, but it will still be a long time before a large enough portion of servers are upgraded for this to make sense.

Besides, there is no rush. CodeIgniter works nicely as it is and is a great tool for getting applications made without constantly having to recode things just because we figured it would be nice to throw in some namespacing. ;-)
#77

[eluser]Rick Jolly[/eluser]
[quote author="Phil Sturgeon" date="1297825219"]
As for the loader, I'm not sure. Some people want to change the loader to let it allow anything to be sent to the constructor. I'd be all for that change instead of just documenting the rather odd behavior that exists at the moment.[/quote]
Take note. This is exactly the kind of change wiredesignz is upset about. The loader class doesn't need fixing - it needs to be eliminated. Now Basketcasesoftware is off writing a new library loader like he's just discovered php 4.
#78

[eluser]Phil Sturgeon[/eluser]
[quote author="Rick Jolly" date="1297921628"]Take note. This is exactly the kind of change wiredesignz is upset about. The loader class doesn't need fixing - it needs to be eliminated. Now Basketcasesoftware is off writing a new library loader like he's just discovered php 4.[/quote]

He was offering to document existing functionality to avoid confusion over a quirk that everyone knows about. I suggested it might be better to stop non arrays being converted to a NULL in the constructor. Nobody is talking about re-writing or removing the Loader class.

CodeIgniter works the way it does, and it's obviously going fairly well because we are here. Sure we could rewrite everything and make it use some great PHP 5 autoloading, rewrite the core and go nuts with namespaces while we're at it, but what exactly is the point of that?

If we remove the Loader class right now, people will kick off a lot more than the few complaining about it still being there. Small incremental changes are the name of the game right now, not a full recode. I think the majority will agree with this approach.
#79

[eluser]Basketcasesoftware[/eluser]
Probably true, Rick. But for me it's an exercise to better familiarize myself with the existing code base "under the hood". It's also a "proof of concept" issue. Right now I'm just working with one method in the entire class and trying to do so in a manner that doesn't break any legacy code.

How would you suggest eliminating the class? Right now one of the features of CI is "lazy loading". Nothing is loaded unless it is absolutely essential and even then it is loaded under programmer direction. The loader class seems to all the fulfillment of that objective. Maybe just creating an instance of each class in much the same way as the DataMapper system does its model class might be reasonable but that would break a lot of code. Already people complain about the problems with the switch from 1.7 to 2.0 CI.

You notice I didn't bitch about how things are done, I went and tried actually doing something constructive in an open, accountable manner. I have 30+ years in IT. I have nearly about 36 years in electronics. I have about 25 years in advanced calculus and statistics. And that's just a start. This is all good, but it isn't worth a spit unless I apply it constructively.
#80

[eluser]Basketcasesoftware[/eluser]
[quote author="Phil Sturgeon" date="1297922433"][quote author="Rick Jolly" date="1297921628"]Take note. This is exactly the kind of change wiredesignz is upset about. The loader class doesn't need fixing - it needs to be eliminated. Now Basketcasesoftware is off writing a new library loader like he's just discovered php 4.[/quote]

He was offering to document existing functionality to avoid confusion over a quirk that everyone knows about. I suggested it might be better to stop non arrays being converted to a NULL in the constructor. Nobody is talking about re-writing or removing the Loader class.

CodeIgniter works the way it does, and it's obviously going fairly well because we are here. Sure we could rewrite everything and make it use some great PHP 5 autoloading, rewrite the core and go nuts with namespaces while we're at it, but what exactly is the point of that?

If we remove the Loader class right now, people will kick off a lot more than the few complaining about it still being there. Small incremental changes are the name of the game right now, not a full recode. I think the majority will agree with this approach.[/quote]

Exactly. Truth be told I am trying at a later point for a rewrite just to see if certain PHP 4 to PHP 5 conversion can be better done without breaking existing code, but I'm planning on using code wrappers for that. I have been rewriting the library load method but all I've mostly done is just put in a detailed decision tree and experiment with the usage of the map_array function. I'm also commenting what I'm doing in detail. So far I've had positive reviews from those who've actually messed with my work. It's a small thing, but I'm taking the time and effort to study it closely and do it well. I'll admit I've expanded some functionality slightly though simply by considering the possible input combinations of the function and considering the functions purpose.




Theme © iAndrew 2016 - Forum software by © MyBB