[snip]
> Josh, I am interested in what you mean by "but there may be a better
> overall approach."
The reason I say that is because, though I'm no expert on application
design, in my own code I've found that whenever I'm tempted to use a big
switch, it's probably a better idea for me to make a cl
> Josh, I am interested in what you mean by "but there may be a better
> overall approach."
(which was in reference to my original question which was: why are you
using a big switch?)
The reason I say that is because, though I'm no expert on application
design, in my own code I've found that whe
Jay Blanchard wrote:
> [snip]
> Richard Lynch speaks:
> But it ends up being not all that maintainable, and you end up having to
> open up and track too many files with too many interactions when you go
> down this route.
>
> I abandoned this style and have never regretted it.
>
> YMMV
> [/snip]
>
[snip]
Richard Lynch speaks:
But it ends up being not all that maintainable, and you end up having to
open up and track too many files with too many interactions when you go
down this route.
I abandoned this style and have never regretted it.
YMMV
[/snip]
In favor of what?
--
PHP General Mailin
Jamie Alessio wrote:
> BUT, also from documentation on http://us2.php.net/include/ it looks
> like your example might not hold any water either. "Be warned that parse
> error in required file doesn't cause processing halting." Based on that
> it appears that introducing the parse error in foo2.php
Jay Blanchard wrote:
> switch($action){
> /* several dozen cases to follow */
> case "foo":
> writing out all of the code
> break;
> }
>
> and this
>
> switch($action){
> /* several dozen cases to follow */
> case "foo":
> include that will
[snip]
BUT, also from documentation on http://us2.php.net/include/ it looks
like your example might not hold any water either. "Be warned that parse
error in required file doesn't cause processing halting." Based on that
it appears that introducing the parse error in foo2.php doesn't prove
that
Assumably, if includes were processed before the script was
executed, it would show a syntax error in foo2.php. We ran
Good point about the syntax error.
the test (v 4.2.1) and no error was returned, so that pretty
much answers the question (READ: includes are not processed
until they are calle
[snip]
> I appreciate all of ya'll's insight on this and for setting me
straight
> on the includes/requires band wagon. I made some incorrect assumptions
> (and didn't run the simple tests I could have run myself, as a couple
of
> you have pointed out) and I will now have to eat some crow in front
[snip]
You're wrong. The include() and require() statements are only evaluated
when they are reached in your application code, so there is a big
difference between your two examples. In you use the second example the
code will only be included by PHP if the application logic enters the
case stateme
>> This doesn't prove the case either way.
>>
Nice catch on that one but actually there might be another problem with
my example. According to example 16-8 on http://us2.php.net/include/
"Because include() and require() are special language constructs, you
must enclose them within a statement
Consider yourself bytten, RTFM indeed! (BTW, this behavior is not really
mentioned anywhere that I can find in TFM, it is more or less an
assumption to be made from an example which would not prove the include)
OK this is the last time I push the button on this one, but since you
asked ;)
http://
> Just out of curiosity, a lot of people had answers to this question, but
> I couldn't find a shred of evidence in the
> documentation. Did you do similar tests, hear from gurus, or something
> of like? Or did I just miss it somewhere?
Once upon a time, a long time ago, require and include were
[snip]
You're wrong. The include() and require() statements are only evaluated
when they are reached in your application code, so there is a big
difference between your two examples. In you use the second example the
code will only be included by PHP if the application logic enters the
case stateme
Remember, I am old school. My first programming venture was in the 70's
with FORTRAN, so all of you young bucks view programming differently
than I do. I have a tendency to view things more from a C or C++ POV in
I am indeed a young buck... but now I find myself moving (backwards?)
because I have
Jay Blanchard wrote:
Remember, I am old school. My first programming venture was in the 70's
with FORTRAN, so all of you young bucks view programming differently
than I do.
Old fart. I didn't venture into programming until 1980 with BASIC on an
Atari. ;)
Somebody wake-up grandpa Jay...he fell
[snip]
>
> Otherwise, I'm curious as to why you're using a large switch, not that
> it's bad inherently IMHO, but there may be a better overall approach.
>
> /jw
I don't know why *he* wants to do it, but one useful example is the MVC
model (google "MVC phppatterns" if you're unfamiliar with t
Otherwise, I'm curious as to why you're using a large switch, not that
it's bad inherently IMHO, but there may be a better overall approach.
/jw
I don't know why *he* wants to do it, but one useful example is the MVC
model (google "MVC phppatterns" if you're unfamiliar with the term).
For a gi
Jamie Alessio wrote:
Correct me if I am wrong, but includes (and/or requires) will get all of
the code in all of the cases regardless if the case is being processed.
You're wrong. The include() and require() statements are only evaluated
when they are reached in your application code, so there is
> If I have a large app what is the difference, other than having a very
> large file, of doing this
>
> switch($action){
> /* several dozen cases to follow */
> case "foo":
> writing out all of the code
> break;
> }
>
> and this
>
> switch($action){
> /* se
Correct me if I am wrong, but includes (and/or requires) will get all of
the code in all of the cases regardless if the case is being processed.
You're wrong. The include() and require() statements are only evaluated when
they are reached in your application code, so there is a big difference betw
21 matches
Mail list logo