On 01-02 16:06, Jaime Bozza wrote: > Returning false is invalid for the session read function, and has caused > *MANY* issues with PHP and Sessions. (Check the archives as well as the > bugs database. I have a couple in there myself) > > Change: > return false; > > To: > return ''; > > And things should start working as expected.
As near as I can tell, things *are* working, but I'll change it to return the ''. What an odd thing to require - I guess it's because it is expecting a string in the "true" case. I've noticed that for the most part, PHP allows you to do things very easily, is very extensible, and yet, for something so (relatively) new, it has a lot of well, ugly, "features" like this. I don't mean to knock the whole project, as it's very cool, and I'm sure very hard work to maintain - but DB access is pretty weird, and the calls vary across DBs - I ended up coding a bit of my own thin layer to generically call DB functions, and not have to worry about mysql_foo, pgsql_foo, etc. It seems that it would be pretty easy to have that as part of the language. It's rough edges and strange issues like that that just make me scratch my head. Every single language I've worked with has them (what I call "isms" - Java-isms, PowerBuilder-isms, C-isms - I can usually become productive with the core of a language pretty quickly - usually inside of a week, as any good programmer can, but the "isms" can be the part that take a few months to get right - try telling any HR person/hiring manager that, and you won't get far, though. :) They still want X years of Y, W years of Z, rather than doing some simple aptitude type of testing, or going on recommendations, nah, let's just scan resume for keywords and time periods...no wonder they claimed they couldn't find people before the recession.), but PHP just seems to have some really weird ones that you think would be easily remedied. That being said, doing session type stuff in PHP is still a ton easier and more intuitive, IMHO, than mod_perl or some Java app servers. Also, since it's a built-in, it's rare that from project to project it will vary. Even when there are "best practices" for things like this in a language/environment, I still seem to inherit code where people go skipping down the bunny trail doing some weird and buggy stuff because they didn't know what they were doing - when it's built in, that's less likely to happen. The db layer I mentioned above would prevent just this sort of thing - maybe this is already a planned feature? -- Sean LeBlanc:[EMAIL PROTECTED] Yahoo:seanleblancathome ICQ:138565743 MSN:seanleblancathome AIM:sleblancathome Errors using inadequate data are much less than those using no data at all. -Charles Babbage (contributed by Chris Johnston) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
