On Wed, 2007-12-12 at 10:47 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> >> I can't remember what sort of environment the OP was in, but if any
> >> sort of organised testing is done, the use of two different APIs will
> >> just about double the test-effort. Which is why I still think th
On Dec 12, 2007 4:47 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Robert Cummings wrote:
>
> >> I can't remember what sort of environment the OP was in, but if any
> >> sort of organised testing is done, the use of two different APIs will
> >> just about double the test-effort. Which is why I stil
Robert Cummings wrote:
>> I can't remember what sort of environment the OP was in, but if any
>> sort of organised testing is done, the use of two different APIs will
>> just about double the test-effort. Which is why I still think the
>> best option is to mandate _one_ of the APIs and choose you
On Tuesday 11 December 2007, Per Jessen wrote:
> Stut wrote:
> > I couldn't care less what your domain name is, you're still advocating
> > a poor choice IMHO.
>
> I have been trying hard not to join this thread, but ... apart from the
> principle, what's _really_ so poor about it? Having to write
On Dec 11, 2007 4:11 PM, Per Jessen <[EMAIL PROTECTED]> wrote:
> I can't remember what sort of environment the OP was in, but if any sort
> of organised testing is done, the use of two different APIs will just
> about double the test-effort. Which is why I still think the best
> option is to mand
On Tue, 2007-12-11 at 22:11 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
> >> I have been trying hard not to join this thread, but ... apart from
> >> the principle, what's _really_ so poor about it? Having to write
> >> application
Robert Cummings wrote:
> On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
>> I have been trying hard not to join this thread, but ... apart from
>> the principle, what's _really_ so poor about it? Having to write
>> application code that needs to work with two different APIs is poor
>> enough
On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
> Stut wrote:
>
> > I couldn't care less what your domain name is, you're still advocating
> > a poor choice IMHO.
> >
>
> I have been trying hard not to join this thread, but ... apart from the
> principle, what's _really_ so poor about it?
On Tue, 2007-12-11 at 17:01 +, Richard Heyes wrote:
> >> Real life is rarely optimal.
> >
> > That's not a valid excuse for taking the sloppy pig route to
> > development. Sloppy pig's give conscientious developers a bad name. And
> > when they use PHP to create their slop, they give PHP a bad
I don't see a reason to compromise. It would take no longer to call
extension_loaded on each page request than it will to put the variable
in the session. You're right in saying that there's a balance to be
struck, but in this particular case I personally see a right way and a
wrong way and no
Stut wrote:
> I couldn't care less what your domain name is, you're still advocating
> a poor choice IMHO.
>
I have been trying hard not to join this thread, but ... apart from the
principle, what's _really_ so poor about it? Having to write
application code that needs to work with two differen
Richard Heyes wrote:
Real life is rarely optimal.
That's not a valid excuse for taking the sloppy pig route to
development. Sloppy pig's give conscientious developers a bad name. And
when they use PHP to create their slop, they give PHP a bad name.
Well I err towards actually doing something
Real life is rarely optimal.
That's not a valid excuse for taking the sloppy pig route to
development. Sloppy pig's give conscientious developers a bad name. And
when they use PHP to create their slop, they give PHP a bad name.
Well I err towards actually doing something useful. Businesses can
On Tue, 2007-12-11 at 16:31 +, Richard Heyes wrote:
> > Sre, sessions are for whatever you choose to put in them. That's
> > like saying bodies are for whatever a crazed murderer chooses to put in
> > them...
>
> No it's not.
Yes it is. Neither is a good argument.
> > the statement
Sre, sessions are for whatever you choose to put in them. That's
like saying bodies are for whatever a crazed murderer chooses to put in
them...
No it's not.
> the statement is true, but it's not optimal.
Real life is rarely optimal.
--
Richard Heyes
http://www.websupportsolutions.co.
So? It's there - use it.
So are cookies, would you stuff this into a cookie? No, because that's
not what cookies are there for.
Not because "it's not what cookies are for" - but because sessions are a
more efficient and easier to use storage medium.
You could potentially be pointlessly dup
On Tue, 2007-12-11 at 15:25 +, Stut wrote:
> Richard Heyes wrote:
> >> Because it's not user data, it's server data.
> >
> > So? It's there - use it.
>
> So are cookies, would you stuff this into a cookie? No, because that's
> not what cookies are there for.
>
> "Because it's there" is neve
Richard Heyes wrote:
Because it's not user data, it's server data.
So? It's there - use it.
So are cookies, would you stuff this into a cookie? No, because that's
not what cookies are there for.
"Because it's there" is never a good reason to do something.
That's entirely the wrong place
Because it's not user data, it's server data.
So? It's there - use it.
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
Yeah, really. Sessions are for user data. I
Stut wrote:
> However, I'd expect a stat on that
> file will be more expensive than calling extension_loaded.
Difficult to say, but a stat() is cheap, especially if the inode is
cached already.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://
Stut wrote:
> Richard Heyes wrote:
>>> You use a session variable for that?
>>
>> Why not?
>
> Because it's not user data, it's server data.
>
>>> That's entirely the wrong place to
>>> store something like which database API is installed.
>>
>> Not really. You could even wrap a function called (
Richard Heyes wrote:
You use a session variable for that?
Why not?
Because it's not user data, it's server data.
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
You use a session variable for that?
Why not?
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
> It should a class
variable or global configuration variable. Heck,
On Tue, 2007-12-11 at 13:02 +0900, Dave M G wrote:
> Zoltan, Per, Richard, Chris, Daniel, Larry,
>
> Thank you for responding.
>
> I have created a method in the class that handles my database
> connections that will first test on extension_loaded(mysqli) before
> connecting to the database.
>
Zoltan, Per, Richard, Chris, Daniel, Larry,
Thank you for responding.
I have created a method in the class that handles my database
connections that will first test on extension_loaded(mysqli) before
connecting to the database.
Then I store the result in a session variable for reference, so
25 matches
Mail list logo
