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]

Reply via email to