Re: general question re PHP OOP support

--- Hank Marquardt <hmarq(at)yerpso.net> wrote:
<snip>
> What makes you think you need to completely rewrite
> it?  OOP isn't a
> panacea and procedural code isn't evil -- seems like
> you could spend 1/3
> the time of a re-write to clean up the code, remove
> duplication and
> build yourself a library -- but that isn't the
> question you asked:)

Close enough, tho (-:  Actually your point is
something I've thought about, but you've encouraged me
to think about it some more, so thanks.

<snip>
> Of course I grew up 'procedurally' and
> OOP for me is a forced exercise and some things just
> seem *wrong* to me
> --
> 
> print $a; is intuative to me
> a.sys.writeln; seems stupid to me

Here's a little Perl humor along those lines:

HelloWorld->new->print;

package HelloWorld;

sub new { 
    return bless {}; 
}

sub print {
    print "Hello World!\n";
}

> That said, I use objects in projects where they make
> sense -- my database stuff is OO, I generally have 
> class for each central character
> of a project ... that might be a 'member' in a
> membership/subscription site --- in your case that 
> > might be a an 'interpreter'.

Especially in a language like PHP, which I think
encourages you to do your own thing, it makes sense to
mix and match your styles and techniques according to
what seems the most natural and sensible.

I guess the reason I have a code cleanup linked in my
mind with a more OO approach is that OOP so strongly
encourages -- indeed, requires -- code re-use. And it
encourages *planning*, a skill in which I'm admittedly
little weak (too inclined to just start coding now and
see where it goes). I'm drawn to the idea of cutting a
600 line PHP page down to a 60-liner with a few method
calls. True, you could do the same with non-OO
function calls. But the more complex something is, the
greater the urge to use classes and objects to
simplify things, or at least hide the complexity under
the hood.

> 
> I think your real decision is whether you should
> move this off of a web
> based interface; and if the answer is yes, then
> perhaps you should look
> at alternatives -- perhaps Python? ...

Honestly, it's web based primarily because that was
the way I knew (more or less) how to do it when the
project began. And certainly, it's sometimes extremely
convenient to be able to access it from anywhere you
have a browser and a connection. But I've been looking
for a good excuse to learn Python, too (-:

> [...] but if you're
> staying web based,
> I don't think a better language exists than PHP.

Amen to that.

Actually there's another closely related issue -- I'd
like to be able to pack up all these files into a 
tarball and say, "here, take it" to colleagues in the
court interpreting industry (who do need it, I assure
you). It would seem that the simpler and cleaner the
code, the easier for them to install, configure,
perhaps have their local geek hack a few things if
needed. Right now I feel like the more I work on this
thing in its current state, the more work I'm creating
for myself down the road, when the time comes to get
serious about cleaning it up.

Thanks -- it's instructive and fun to talk about
generalities like this with one's more experienced
peers.

David Mintz
Spanish Interpreter
US District Court, SDNY
Personal http://panix.com/~dmintz/
Web design & hosting http://dmintzweb.com/






__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

HWG: hwg-languages mailing list archives, maintained by Webmasters @ IWA