General observation about mods and themes

Started by Rozak, February 02, 2007, 08:27:27 AM

Previous topic - Next topic

bloc

I am sorry, but you also assume a lot of things here.

And one of them is the notion that the guy that wrote most of this software base code didn't know what he was talking about. I am not going to pretend that I know all these things, I don't. But I can follow the logic mostly and what he said there about php being different from for example what you are working with: compiled code rather than run-time executed code, is something that makes sense. Results speaks for themselves and this script speaks volumes. Not my words either, but of many others, more knowledgable than us too I guess - of course not knowing you at all.

For my part I will stick with what I do know lol :). Resorting to arguments about who said what isn't fruitful by any stretch, FYI.

Joshua Dickerson

I kind of disagree with Bloc's statement about themes not being for mod makers. I think all themes and mods are customizations. So, differentiating them as broadly as "theme" and "modifications" is not really highlighting what they actually do. Nearly all "mods" modify a theme in some manner.

I think the idea that Bloc has is great. I think a more modular system would be best. I started work on something similar, using tags, a while back. Alas, I have no time to work on it now. It isn't a feature of SMF, it is a tool. Pretty much, it replaces the tag with a block of code. The block of code is stored in a separate file. That block of code can be changed as greatly as you want. Each block can have sub-blocks which would be parsed in the same manner. They are all compiled to create a theme that would then be as fast as your normal theme. It wouldn't require a lot of extra functions to be created on each load of the script.

Next thing - what would be the benefit of using OOP for everything in SMF? I think there are a lot of benefits of OOP, but like has been said, it isn't useful everywhere. The speed loss of OOP is negligible, but the speed lost by using a multi-leveled array isn't? Have you done any benchmarks to prove that? There have been a lot of benchmarks on PHP OOP/procedural. Procedural still beats out OOP in everything that I have seen. It might not be a lot, but when doing something on such a low level in a script, it will snowball. Want to make it easier for a user to modify their board? How does OOP help with that? I can only see it as making it harder. Also, the developer's preference would matter a lot in this. If a developer doesn't like working with OOP, it would be prudent to not use it. I can understand that users may want that and I think users dictate the future of SMF, but they also want a working product. To achieve a working product, they need to give the developers freedom to use the tools in their arsenal in the manner that they prefer.

Chris Curran: events as in actions? What is inefficient about that? It is actually the most efficient way to handle it. I know because I have done benchmarks on many different ways to do it. You keep saying that we shouldn't move to a complete OOP model, but in the very beginning you said "IMHO, SMF v2 first and foremost should be entirely based on classes. In short, SMF should move to an OOP model."

How many people do you think use PHP 5 compared to 4? It is unfortunately not a good number. Most shared hosts are still using PHP 4. We can't ostracize our users that use PHP 4. Eventually, I hope to do that ;) but I couldn't even hope for that when so many users still use 4.

Now, don't get me wrong, I have used OO-PHP for many things. Including using it to create my own (not totally working) SM Framework based entirely on the SMF code. I am also a realist and in reality it isn't best suited in total for SMF. There are very few cases where it would be better than procedural PHP.

Chris, don't think this is something hard-wired in to my (or our) brains. I have done a lot of testing and research in to OOP.
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

bloc

I can go along with that, themes and mods are intertwined.. :)

And the idea of compiling a theme with for example using xml tags is something I like to pursue at some point too..but for now I'll simply separate things, making it easier for both the modder to hang instructions upon, and allowing the thememaker to paint with broader strokes lol. :) the compiling will touch similar things, but if its coimpiled into the "old" code again, it makes it still hard for mods.

Chris Curran

#43
Bloc,

Uhh, no, I think you are assuming things here. What makes you think I have such a negative view of the folks who wrote SMF? The *last* thing I think is that they didn't know what they were doing. Geezy weezy, no way. The opposite is actually true - I'm rather impressed with the quality of the current code set. Do you really think I would bring up OOP if I thought the developers where a bunch of morons? The rest of your post I don't understand...

cheers

Chris Curran

#44
groundup,

>Have you done any benchmarks to prove that?

Well, actually, I have done quite a few benchmarks regarding this over the years. As CTO of tylernet.com I oversaw a large project that was written in php5 OOP for a customer of ours (Tweeter, ya ever hear of them? :)). However, my benchmarks won't tell you anything as anyone who has been in this business long enough know, generalized benchmarks almost never transfer over to the real world environment. I went the OOP route because it offered an improved model that would benefit the young-bucks I'd hired for the project (all kids fresh out of college).

>How does OOP help with that?

When done well, it organizes the code and data into a cohesive chunk that's easier to modify/control/manage. I'll not list the other items as they can be found in any text on the subject.

>If a developer doesn't like working with OOP, it would be prudent to not use it.

:)... And if the developer prefers OOP, it would be prudent to use it. If you want to attract untrained weekend-warrior programmers, avoid OOP. However, every programmer that's been through any basic 4 year degree is going to be steeped in OOP practices and will expect the same when they hit the real world. Last year I started up a new project a Tyler and did the hiring thing. Every young-buck that walked through my door tried tp impress me with how oop crap they could spew.

>I can understand that users may want that and I think users dictate the future of SMF

Users? Who is "user"? Uhh, I've been braking my arse working on the Calendar code adding features that by all accounts should have been there to begin with. That was more than a year ago, and since then have all but begged to get help with the mod process. None came. This attitude you present here is part of the problem I see with SMF. SMF wants to tout it's expandability due to mods, yet SMF seems to treat the mod writers with such disdain that I for one am very un-impressed.

>Chris Curran: events as in actions?

No, events as in calendar events.

> but in the very beginning you said

You skipped over the middle part. The part were everyone acted like I pissed on their cornflakes when I mentioned "php" and "classes" in the same sentence ("We said it before and we'll say it again" by God, don't mention this!). Since it was obviously that wasn't going to happen, I've been trying to get a smaller point across - encapsulate key data structures in SMF.

>How many people do you think use PHP 5 compared to 4?

I agree, this is a valid issue. However, a year, or two from now what will be the PHP4 usage?

> I have done a lot of testing and research in to OOP

Me too. It's hard to write C++ compilers without know a little about the topic... :D I think you have the impression that I'm some kind of OOP freak. Not so. I like some of the practices and principals that OOP offers, but I also know when to crank up the assembler. Well, actually I can't imagine resorting to asm these days as even firmware dev is done with a C compiler these days... but I digress.

cheers

Ensiferous

#45
Quote from: groundup on March 10, 2007, 02:38:15 AMHow does OOP help with that? I can only see it as making it harder.

Then you fail at understanding what's OOP is actually about, one of the basic elements of OOP is to ease  extending other peoples code, that's why they introduced classes, renamed functions etc. You can't make a file/function abstract, you can with OOP. So in other words OOP was made to make it easier to  extend code, the power of saying "override this method with what you need to happen" that's powerful, and it would be perfect for something which needs to very customizable.

Quote from: groundup on March 10, 2007, 02:38:15 AM
How many people do you think use PHP 5 compared to 4? It is unfortunately not a good number. Most shared hosts are still using PHP 4. We can't ostracize our users that use PHP 4. Eventually, I hope to do that ;) but I couldn't even hope for that when so many users still use 4.

But to go for the lowest common denominator is perfectly fine? No one said anything about ostracizing your php 4 users, they already have a great product and no one says you have to stop developing for them either. At some point you will have to leave behind the previous versions, actually give users a reason to upgrade, it's no wonder no hosts have php5 when no one uses it.

I'd say that with the release of php 6 it would be an optimal time to say that the users still lacking behind with php 4 will have to use the product which already works and make do with security updates only. (you don't optimize your websites for IE 5 anymore do you?)

With php 6 the oop model in php will be even more developed, register_globals will be permanently gone and magic quotes too, already there you have a lot of checking you don't have to do so development will be faster.

APC will also ship with php 6 which will virtually remove any overhead of having to recompile the scripts everytime as APC will cache them. (people ought to use this with both php 4 and 5 anyway)
So your speed argument will by then be reversed. ;)
My Latest Blog Post: Debugging Nginx Errors

Joshua Dickerson

I know very well the benefits of OOP. I also know the downsides. I don't think moving to a completely OOP structure will be of use to us. Then again, you could always come up with a proof of concept ;)

Chris: I am sorry if I am presenting an attitude of not caring about mod authors. I am trying to do the exact opposite. Trying to get the views of everyone and trying to implement changes.

NoFear: the speed argument still exists, but it is less useful at that point.
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

Ensiferous

I'm not advocating a 100% OO structure that would be silly in PHP, I'm saying that seperating and encapsulating core areas of the forum would be beneficial to mod makers and people looking to integrate to a larger extent than SSI/smf_api allows to, currently it involves extracting the code and fixing it to not use every single aspect of the SMF code. (because that would be slow) The problem with this of course is that should SMF update every part of the integration would have to be updated too, or at least checked to make sure it was not outdated.
My Latest Blog Post: Debugging Nginx Errors

Joshua Dickerson

The same can be done with procedural. See MVC architecture. That is the architecture that the developers are working toward.  
Come work with me at Promenade Group



Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

Ensiferous

A model-view-controller architecture is not reserved for procedural code though, while I agree it is what SMF should be based on I also believe OOP would be ideal to archive this.
My Latest Blog Post: Debugging Nginx Errors

Dannii

Quote from: Chris Curran on March 10, 2007, 11:01:17 AM:)... And if the developer prefers OOP, it would be prudent to use it. If you want to attract untrained weekend-warrior programmers, avoid OOP. However, every programmer that's been through any basic 4 year degree is going to be steeped in OOP practices and will expect the same when they hit the real world. Last year I started up a new project a Tyler and did the hiring thing. Every young-buck that walked through my door tried tp impress me with how oop crap they could spew.
That doesn't mean that OOP-loving programmers are the best type of programmers ;) Aparently what made Google scalable is functional programming.
But OOP could be useful definately. Somethings, like visual verification, could work very well as classes that implement a specific interface. Overall though, procedural seems the best model for PHP, as the process of building a webpage is largely linear.

And btw, feel free to completely rewrite the calendar system. It's bloat and should really be a mod.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Advertisement: