General observation about mods and themes

[bloc]

Thats exactly the purpose of dividing things into functions - being able to move it around easily.

Themes are foremost made to present information and as such is the working tool for theme makers foremost - not mod makers. This is something that might help that a little, but I must stress that its something to help theme makers for the most part.

[Rozak]

dont disagree with any of those comments and particularly agree with the point of 'slowing things down' - there is a point where it becomes 'too much' - but a little more to remove some of the 'help' cries will (I think) go a long way

[Chris Curran]

Rozak,

I too have struggled with many of the issues you speak of. Abstraction layers are a good thing, most of the time. However, before the team runs off with this, IMHO the team should first consider moving the entire codeset to php5 classes. I've been hacking the calendar code for about a year now, and all those arrays being indexed is not only problematic to read/maintain, it's also a performance pig.

I have spent a good deal of time working on a calendar set of source files that use php5 classes. It's far easier to read, maintain and therefor extend. For example, there are no unknown members in my event class; quick go open a source file and list all the variables that are used in the event handling of SMF. You can't (without cheating and using grep<g>).

An abstraction layer alone won't work for everything (with un-classed SMF). For example, my calendar mod removes the "span" logic and replaces it with true repeating events. An abstraction layer wouldn't work for this application as I need to *replace* the code in the base codeset.

IMHO, SMF v2 first and foremost should be entirely based on classes. In short, SMF should move to an OOP model. Then, adding an abstraction layer becomes almost trivial (if needed). This also solves a LOT of the problems you mention about the mod process. In most (all?) cases it will no longer be necessary to use the mod process to change/remove/ code from the base SMF codeset - you simply inherit the SMF base class, override the function you need to modify/replace and you're off to the races. The original SMF source is left untouched.

cheers,
Chris

[bloc]

That would take a major rewite of SMF, something that will take time, make versions unstable for a long time and will mean little to the templates, which will need its html output regardless. Besides, one of the key elements of SMF is its speed - moving to OOP will slow it down, even more so on PHP 4 I guess, which still a lot of people are using.

Modding sources files isn't the biggest problem - they don't change - but theme templates do.

[Chris Curran]

Bloc,

Without question, many things would change. However, adding an abstraction layer to SMF will require a lot of the same work and break most of the same things you mention (including stability). I can't agree with your assertion that "Modding sources files isn't the biggest problem - they don't change - but theme templates do". Take a look at the topics in this forum - very few are about themes.

I'm curious why you seem to think that moving to classes will slow things down. Accessing a class instance is far more efficient than $var['index1']['index2']['index3']. All those multiple layers of indexing using associative indexes are very expensive wrt performance. However, moving to an OOP model isn't strictly about performance - it's about organization of an increasingly complex system. If performance was the only metric worth measuring, then SMF should be written in C (or asm if you want to get real crazy).

PHP4... Yea, but maybe it's time that SMF v2 did what Apple did in the 80's - break compatibility with the past in order to release a revolutionary product....

Lastly, I'm not sure why you say it wouldn't be of use to the templates. Why couldn't the templates simply override a "paint()" method (or whatever you want to call it)?

These are just ideas that I'm tossing out here - I'm not trying to change anyone's "religion".

cheers,
Chris

[JayBachatero]

We have stated in the past and will say it again.  SMF will not go OOP.  OOP is not the solution for everything.  We have some OOP in SMF but small parts of it.  Parts that take advantage of OOP like package manager and the ftp class.

[Chris Curran]

We have stated in the past and will say it again.  SMF will not go OOP.  OOP is not the solution for everything.  We have some OOP in SMF but small parts of it.  Parts that take advantage of OOP like package manager and the ftp class.

Wow. Sounds like I hit a nerve. I didn't say it was for eveything. You recently started that you were just starting to learn OOP, so I'm a little curious why you're so certain it's the wrong solution?

You folks don't want oop in SMF? Sure, fine, OK. Didn't mean to get everyone up in a roar over what I thought is a good idea. I won't mention it again...

[bloc]

Its not about that..although this discussion has some past history where answers were given that adressed what you asking. Check out this topic:

http://www.simplemachines.org/community/index.php?topic=24567.0


But the issue here is to make mods work better with multiple themes. Because, as I already said, modding Sources files isn't a problem(unless there are many other mods, but thats inevitable and also seems to work fine for the most part) - but modding themes other than default is.

Thats what i am trying to adress + a simplication for theme makers overall. I am not sure it will be the way to go, but I want to try.  

[Ensiferous]

I actually started writing about what OOP is because it sounds as if there is a certain bias towards the old ways of procedual, and I don't mean old ways in a bad way, procedual code still has it's places; yet OOP could certainly help the forum a lot.

To address the speed issue; about a year ago I migrated a site from procedual programming to OOP, it did not suffer much in execution speed and since then the PHP developers has address every speed issue in the php 5 branch making it equally fast.

I'm curious why you are dislike OOP in PHP so much, the argumentation in this thread is very weak and most of all just shows a bias towards procedual programming. The thread linked is a discussion from two years ago with a developer who is no longer active with SMF. While I admit Unknown is an excellent programmer many of the points he raised in his original argumentation just aren't valid anymore; as previously stated the speed difference is negligible. His point that many of the principals of OOP isn't very well developed for PHP is no longer valid either. To use his own example; it is now possible to type hint as to the type of a parameter (array/object) much like you make an explicit cast. The fact that type hinting sort of defeats the points of PHP is an entirely different discussion.

Using OOP for SMF would allow for far easier integration with external scripts, i.e. websites looking to create integration, by having seperated classes for each key area of the script one can easily include the required files, instantiate the Login/Registration/Clever name for misc functions class and provide his own sanitized data to the class. (or you could chose to sanitize the data in-class to make sure newbies don't expose their sites) Doing so would also prevent the overlord class as Unknown correctly pointed out.

Planned and programmed correctly OOP could really make a forum software unmatchable by anyone else unless they followed suit; I also reckonize that it would require a tremendeous amount of work archive this, it would be nothing short of a rewrite, sometimes those are needed though as ones skills improve. I'd be more than happy to assist with both planning and creating an OOP version of SMF, it would be perfect for me as I often create sites which needs integration and using the smf_api is not always easy and requires a lot of hacking. And please don't say it's not supported anymore and to use SSI instead, if you do some simple profiling, you will find out that smf_api is upwards of 900% faster than SSI.

[Chris Curran]

http://www.simplemachines.org/community/index.php?topic=24567.0

Can't say I agree with much of this...

But the issue here is to make mods work better with multiple themes.

Uhh, that's not how I read the opening paragraph to this thread.

Because, as I already said, modding Sources files isn't a problem(unless there are many other mods, but thats inevitable and also seems to work fine for the most part) - but modding themes other than default is.

And as I already said, and as is said in the opening para of this thread, modding Sources is becoming a problem and will become a larger problem as time passes.

Thats what i am trying to adress + a simplication for theme makers overall. I am not sure it will be the way to go, but I want to try. 

Anything that allows a mod to work with more than the default theme would be a plus...

[JayBachatero]

We have stated in the past and will say it again.  SMF will not go OOP.  OOP is not the solution for everything.  We have some OOP in SMF but small parts of it.  Parts that take advantage of OOP like package manager and the ftp class.

Wow. Sounds like I hit a nerve. I didn't say it was for eveything. You recently started that you were just starting to learn OOP, so I'm a little curious why you're so certain it's the wrong solution?

You folks don't want oop in SMF? Sure, fine, OK. Didn't mean to get everyone up in a roar over what I thought is a good idea. I won't mention it again...

Sorry that sounds more like coming directly for me .  Can't quote form my phone.  I believe Compuart made a post about this a while ago as well.  The post was made in the team's board.

[Chris Curran]

Sorry that sounds more like coming directly for me .  Can't quote form my phone.  I believe Compuart made a post about this a while ago as well.  The post was made in the team's board.

Yes Jay, it did sound like it was directly from you, and further is sounded like you were saying "Because I said so"! None of the arguments I've read against the use of oop hold water...

[Chris Curran]

Planned and programmed correctly OOP could really make a forum software unmatchable by anyone else unless they followed suit

Yep, someone was saying something close to that earlier in this thread. Careful though, you're preaching the benefits of a round world to flat-landers!

Psst: I also develop linux kernel drivers for SBIG (www.sbig.com) using oop. So much for slowing things down....

[JayBachatero]

Sorry that sounds more like coming directly for me .  Can't quote form my phone.  I believe Compuart made a post about this a while ago as well.  The post was made in the team's board.

Yes Jay, it did sound like it was directly from you, and further is sounded like you were saying "Because I said so"! None of the arguments I've read against the use of oop hold water...

Sorry if it sounded that way.  I'm not a Core SMF developer.  Right now I'm just a converter developer.  I do plan to use OOP in a personal project that I have in mind.

[Dannii]

OOP in PHP 4 is very different from PHP 5. We could stop supporting one and loose half our users, waste a lot of time implementing everything twice, or keep going how we are now and add new useful features
Which would you prefer?

[Chris Curran]

OOP in PHP 4 is very different from PHP 5. We could stop supporting one and loose half our users, waste a lot of time implementing everything twice, or keep going how we are now and add new useful features
Which would you prefer?

Ahhh, Plauger numbers.... Sir, this is a gross oversimplification.

[Dannii]

It is a simplification, but it's still true. SMF works the way it is now, and the Dev team don't (AFAIK) see any reason to rewrite it into completely OOP code.

[Chris Curran]

It is a simplification, but it's still true. SMF works the way it is now, and the Dev team don't (AFAIK) see any reason to rewrite it into completely OOP code.

It's not true. You assume that everything would have to be dumped and re-written... not so. This alone tells me you don't have a lot of oop experience. Encapsulating key structures would be a terrific start that would not require a lot of effort and return great benefit.

[Dannii]

I have experience. Wrapping everything in classes wouldn't take much effort, but neither would it help much. To properly use the benefits of the OOP model large parts would have to be rewritten.

[Chris Curran]

I have experience. Wrapping everything in classes wouldn't take much effort, but neither would it help much. To properly use the benefits of the OOP model large parts would have to be rewritten.

There is no "proper" use of any OOP model, that's just hooey from some text book speaking. And again, I didn't say wrap everything in a class, but rather to encapsulate key structures. For example, the 'events' data arrays. Working with the events data as it is now is very clumsy and inefficient. All those multiple levels of associative indexing.... yuk.