[feedback] How to bring txp back on track ? Let's debate !

hcgtv · 2006-03-24 01:26:34

I think Textpattern is in a class by itself.

The size of the code base and what it can accomplish is pretty impressive. Comparing TXP to EE is a bit unfair to either project, where EE is aimed at end users with every bell and whistle imaginable, TXP is geared towards the site integrator/designer.

A better comparison would be TXP to pMachine, then we could compare systems on a more equal footing.

Either way you look at it, TXP is Open Source and EE or pMachine is closed source. To me it’s a no-brainer, unless a client required me to use EE, I will always lean towards Open Source.

jtlapp · 2006-03-24 01:38:09

Only PHP 5 has decent OO support

This is an aside, but I differ on this point. PHP 4.3.x has sufficient OO to do modular design. Exceptions are the biggest void, but that’s error handling and not architecture. You don’t have polymorphic signatures, but you can still override base class methods. You don’t have interfaces, but PHP isn’t strongly typed, so you can still pretend you have them. You don’t get multiple inheritance, but you can easily use aggregation instead, and many OO languages don’t allow it anyway.

I think there are two reasons why few PHP programmers do OO: (1) OO takes effort to learn and it’s too easy to just throw something together now with little thought of the future, so the voice of OO programmers is lost in the voice of the non-OO masses; and (2) OO is all about object references, and PHP’s reference mechanism is very unintuitive and hard to grok — this is a virtual killer.

Mary · 2006-03-24 02:29:50

As far as “modularity” you can do that with functions too, which is what Textpattern does, for the most part. OOP has it’s place, and shouldn’t ever be used just because you can. PHP5 has miles and miles beyond PHP4 with regard to OOP, there’s no doubt about it; OOP in PHP4 is hardly OOP at all, in fact.

NyteOwl · 2006-03-24 02:49:01

There hasn’t been much incentive for PHP programmers to really dig in to serious OOP. Only PHP 5 has decent OO support, and for some reason most web hosts still don’t support PHP 5. What’s up with that?

A number of scripts have problems with PHP5, most noticeably cPanel apparently.

zem · 2006-03-24 02:57:18

I think there are two reasons why few PHP programmers do OO: (1) OO takes effort to learn and it’s too easy to just throw something together now with little thought of the future, so the voice of OO programmers is lost in the voice of the non-OO masses; and (2) OO is all about object references, and PHP’s reference mechanism is very unintuitive and hard to grok—this is a virtual killer.

You’re missing (3): sometimes OO just isn’t the right tool for the job.

jtlapp · 2006-03-24 03:15:19

Maybe that’s the problem. People assume you can’t do OO in PHP4 and so don’t.

I have written tons of OO-architected/programmed code for PHP4. Templates, exceptions, interfaces, etc., are all very nice, but they do very little for good architecture and modularity. They are programmer candy and little more. All you need for OO is data/method encapsulation in classes and subclassing with the ability to override method behavior. That one bit of design — encapsulation with subtype variation — is 95% of what OO is. You hardly need an OOP language to do it; OOP just makes it much easier.

If you want to see some serious PHP4 OO, have a look at these EE extensions I wrote:

Filter HTML (my first serious PHP4 project, before I fully understood PHP references)
Batch Module (a zip file)

(I debated whether I should be so prissy as to post these links, but they so readily disprove this PHP4-can’t-do-OO myth, that I couldn’t help it. The idea of committing energy to a project full of don’t-do-OO developers is a bit disconcerting for me.)

I have a more interesting contribution for Textpattern, but I’m not ready to post it yet. It probably has to wait ‘til the 4.1 BSD license, since I tend to publish with the MIT license.

Mary, I agree that you can do modularity with just functions. People were doing OO designs in C before C++ came along: OOP just makes it easier. OO is more a mindset than it is features of a programming language. With functions you just prepend each group of related functions with the same prefix and then use the language’s reflection facilities to dynamically select the function. Subtyping is harder though.

jtlapp · 2006-03-24 03:22:02

Alex: Grrrr. I wish that comment.php code had been more OO.

OO is a mindset for encapsulating and reuse. You can do it without fancy OOP features; those OOP features just make it easier, and often encourages users to do more encapsulation and reuse. (Too many OOP features screw you up, though. Templates, operator overloading, etc. — yuck!)

I have seen very little of the TXP code and don’t yet know it’s penchant for encapsulation and reuse.

zem · 2006-03-24 03:25:34

Maybe that’s the problem. People assume you can’t do OO in PHP4 and so don’t.

I don’t mean PHP OO, I mean OO in general. OO can make things easier. It can also make things harder, even when well designed.

The #1 priority for the Textpattern code is simplicity. When OO helps us keep things simple, we use it. One thing OO doesn’t do well is, take an already simple thing and make it simpler.

jtlapp · 2006-03-24 03:33:34

Alex wrote:

One thing OO doesn’t do well is, take an already simple thing and make it simpler.

I completely disagree, but there’s no way to argue with you. sigh

~joe

jtlapp · 2006-03-24 03:53:26

Alex, I apologize. I do like your response. You have a decent respect for OO. The only sense in which I disagree is that for me OO is the containing architecture of a program, keeping things organized. It doesn’t make sense to me that you choose to use it or not: everything needs a home in that architecture.

Again, I’m sorry for my gut reaction. Apparently I’m on the defensive. You’re keeping a level head.

~joe

Logoleptic · 2006-03-24 05:02:16

NyteOwl wrote:

A number of scripts have problems with PHP5, most noticeably cPanel apparently.

Ah, that explains it.

Sencer · 2006-03-24 12:04:35

but a revamped admin interface seems to be in limbo.

What makes you say it’s in limbo? It’s not anymore in limbo like anything else that has not been done (yet).

OO is a mindset for encapsulating and reuse. You can do it without fancy OOP features;

Pretty funny statement, IMHO. Encapsulation, reuse, (plus unit-testing and a lot of other hip stuff) has been done well before OO, and they didn’t originate with OO. But by redefining everything that uses those concepts as “OO mindset”, OO becomes a winner by default. (It also reminds of this “paper”: My cat is Object-Oriented ). In the same vein everything that becomes problematic in OO, is deemed to be “not real OO”. Deep Class-Hierarchies are more prone to errors? “Not real OO” (but used to be). Yo-Yo Problem in following the execution-flow when tracking down bugs? Due to not real OO. Implementation inheritance leads to tight coupling? “Not real OO” (but used to be). ORM is the called “the vietnam of computer science”? The problem is with DBMS’s not with OO.
The definition of OO is an ever shifting definition, check out this article:
http://mumble.net/~jar/articles/oo.html

Having said that, I do like and use OO, but it’s certainly made out to be more superior than it actually is. And I have gotten somewhat sensitive to the mindset of some of it’s hyper-proponents.

Also there is a slight contradiction, when you (effectively) say that Textpattern could be made simpler by writing it in OO, but then acknowledge that few php-people take the necessary time to learn OO. If you allow me some polemic, then with the same line of argument we could say that re-implementing Textpattern in K would make it easier (for people familiar familiar with K). Of course everybody else would not think of easy when they see this stuff or this stuff. And yes, there are areas where K is extremely popular (rightly so, I’ve been told from people who’se judgement I trust). But Textpattern [obviously] wouldn’t beneft from using K.
Textpattern would benefit from some OO in some places, and when we are working on certain pieces we’re trying to extend or fix, then we do refactor code. Sometimes with and sometimes wihtout using OO-syntax, but usually with the goal of improving readability, improving encapsulation, increasing internal coherence of procedures/classes, and reducing tight coupling where possible.

btw: I think it’s an interesting academic discussion, but we’ve probably gotten pretty much offtopic. So maybe a different thread would be a better place. Because some people do get a very wrong impressions of the state of things by reading the first few pages of this thread (as I tried to explain in my post on page 6).

Textpattern CMS

Textpattern CMS support forum

#229 2006-03-24 01:26:34

Re: [feedback] How to bring txp back on track ? Let's debate !

#230 2006-03-24 01:38:09

Re: [feedback] How to bring txp back on track ? Let's debate !

#231 2006-03-24 02:29:50

Re: [feedback] How to bring txp back on track ? Let's debate !

#232 2006-03-24 02:49:01

Re: [feedback] How to bring txp back on track ? Let's debate !

#233 2006-03-24 02:57:18

Re: [feedback] How to bring txp back on track ? Let's debate !

#234 2006-03-24 03:15:19

Re: [feedback] How to bring txp back on track ? Let's debate !

#235 2006-03-24 03:22:02

Re: [feedback] How to bring txp back on track ? Let's debate !

#236 2006-03-24 03:25:34

Re: [feedback] How to bring txp back on track ? Let's debate !

#237 2006-03-24 03:33:34

Re: [feedback] How to bring txp back on track ? Let's debate !

#238 2006-03-24 03:53:26

Re: [feedback] How to bring txp back on track ? Let's debate !

#239 2006-03-24 05:02:16

Re: [feedback] How to bring txp back on track ? Let's debate !

#240 2006-03-24 12:04:35

Re: [feedback] How to bring txp back on track ? Let's debate !

Board footer