Hello,
On 09/22/2002 03:38 PM, Michael Sims wrote:
>>Basically, it's really easy to create multiple interfaces to the same
>>business logic. Don't try to make things more complicated than
>>necessary, and since there is no need to use multiple languages in your
>>implementation, that is a complexity worth avoiding.
>
> Point well taken. However, allow me to explain some things that I
> left out of my original post:
>
> I decided to go with Perl for a few different reasons. First of all,
> I wanted to get more comfortable working with Perl, mainly so I could
> get exposed to languages other than PHP. I had used Perl in the past,
> but only for small tasks. I saw this project as an opportunity to
> pick up some useful Perl experience.
Good idea, bad project. It is good that you diversify your knowlegde if
that helps your career but I think it is not a good idea to make
technology shift in a project that is already written and working well
in a certain language. I would say the same if the project was written
in Perl and you wanted to change to PHP to diversify your knowledge.
I recommend that you do that in a low risk project that you can start
from scratch. If you do the change now, chances are that you will face
many difficulties and a lot more work than you could antecipate.
> Another reason I went with Perl is because IMHO some of the tasks I
> needed to accomplish are just easier done in Perl. Part of the
> functionality of my script is to parse incoming email and take
> different actions based on it's content. My script responds to
> certain embedded commands (subscription confirmations, unsubscribe
> requests, requests for automated help, etc.). It also forwards
> unknown commands to one set of addresses, while forwarding DSN's to
> another set. This means accepting the mail on STDIN and doing a lot
> of regex parsing. I know that this is more than possible in PHP, but
> Perl just seems better suited to this type of task IMHO.
There is no evidence that is true. Maybe that is just your experience
but doing what you mentioned in PHP is a day at the beach.
Reading from stdin is the same as reading from any file. Just use
fopen("php://stdin","r") to get the file handle.
There are many ready to use components to parse complex e-mail if that
is what you want. If you just need to use regular expressions, you can
do that easily in PHP.
I can tell you that I do that myself in a site of mine and probably
handling more complex situations like handling bounced newsletter
messages. I do it all with PHP hands down. I do not see where Perl would
be better.
Maybe that is my lack of Perl of experience compared to PHP experience,
or your lack of PHP experience compared to your Perl experience.
> In retrospect it probably would have been better for me to implement
> everything in PHP, from a modularization point of view. I could have,
> like you suggested, put all of my business logic in say a class, and
> included that class from both my webpage and my mail script. But that
> would lock me in to using PHP for everything that needed access to
> that business logic, so I'm still not sure that is the best
> solution...
My opinion is that switching to Perl in the middle of a project that
already works well in PHP would be a major mistake. You may want to try
it and realize that yourself at the expense of loosing a lot of time and
probably make your employer very nervous.
Regardless if you switch the language, you will always have trouble to
split the business from the presentation logic from your PHP scripts. My
advice is that you do that just splitting the logic in scripts that you
really need to do that. Resist the temptation of doing that in all scripts.
Also, doing that and switching to a new language at the same time would
make it worse. A sure recipe for disaster. Better safe than sorry.
--
Regards,
Manuel Lemos
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
