General observation about mods and themes

[Rozak]

I've been playing around with SMF now for a few months, building a few different sites for different things - wonderful stuff - the consistent issue I see is that while the application of mods and themese is reasonably automatic in principle, as soon as you add 'enough' it becomes increasingly more and more problematic to add or upgrade. Having now had to hand-hack more and more changes into sites one thing that struck me was the need to have some more standardised 'plug-in' points in the base code.

There are some fairly obvious common places in the distribution code for adding tabs, pages, menu options, admin features, new permissions, $txt[] entries etc - but the community as a whole appears to be somewhat 'lacking' in its adherence to these placeholders.

As I look over the posts and comments in the various mods and themes available for download most of the issues are along the lines of 'it broke my forum' or 'it installed but I cant see it on theme x'.

Having looked over most of the source and spent a long time working my way up and adding several downloadable mods and themes, and now working on my own mods,  it struck me that it might not be a bad idea to populate the distribution code with some 'known' comment blocks - places people can hang modifications on. For example '// INSERT NEW MENU OPTIONS AFTER THIS LINE' springs to mind, or '// PLACE YOUR ADDITIONAL $txt DEFINITIONS HERE' - or at least something that can be searched and used to hang code diffs on.

[bloc]

Good points..and something we aim to improve in future versions. The template files needs some more common "anchors" and sections to search for, both in default theme and certainly in custom themes, where most of the trouble arise.

[Paracelsus]

I support 110% your observation...


MODs and Themes difficult coexistence is for me Achilles tendon of SMF, its weakest point.
Over time, SMF has encouraged the modification process of the base code and it was that small but very important detail that turned SMF into one of the most well-known fast-growing/developing forum system. But one has to put order on this. Customization is good, but chaos is bad. Therefore, I really do believe that the SMF Dev´s have one task to accomplish which somehow seems forgotten: to turn SMF systematic to develop, specially for the average/initiate PHP user.
It´s not that we don´t like challenges (I personally love to cut here, put there, try this and that to customize everything), it´s just that we don´t like to get too frustrated. If for every "average installing difficulty" MOD and Theme we get a "very high installing difficulty" when we put them together, then we start to have a real problem.

[bloc]

Well, the trouble will always be there, as this is somewhat inherent in the system. SMF is not meant to house zillions of mods nor loads of themes. If you install mnay of each, you WILL have a lot of work to do - especially if your website doesn't allow package manager to run for example.

Aside from that, having more common "things" to search for is helpful. But degrading the theme system to make it more "easy" to adjust, will not happen. Thats crippling a very powerful and good feature in which SMF really shines.

[Rozak]

Yes Bloc - agree with you totally, I've tried many many different forum/CMS platforms and finally settled on SMF for a whole pile of reasons - but primarily because the code base itself is pretty simple to get inside and making changes, adding features and generally making it do what you want it to do is generally straight forward. Also agree that if you are going to apply mods you are already in the realms of having to get your php screwdriver out and play a bit to get things working.
The modification/packaging process generally hangs off 'known' text patterns in the code, all well and good when dealing with a reasonably un-tweaked platform - but even something as simple as augmenting the current code base with a few well choosen comment fields would help make that process a bit more robust - and making those who choose to create themes (where >50% of the trouble comes from) can then at least try to make their themes replicate some of the comment.
The other way (and probably a bit more professional ) would be to introduce an additional layer of abstraction in the code for mod and theme creators to use.
By way of example, introducing an additional tab into the main menu across the top of each screen is pretty trivial to do, but still requires some tweaks in the core php files. Having this seperated out into a more 'friendly' configuration file just make it that much simpler.
Anyway - like I said at the start - just an observation and something to park in the mind when looking at v2  

[vbgamer45]

I love some things to be made a little simpler to understand for mod and themes. And for me for mods to install easier on other themes. Would be hard to make these changes for the themes.

[perplexed]

I am not an expert or a coder, but so far for me, my experience of this software and adding mods hasnt been too bad   I recently upgraded to 1.1.2 and currently have 33 mods installed and only had to alter 2 pieces of code, which I think is pretty good, especially for someone like me who doesn't know how to code, but can happily cut and paste

It would be nice if mods could install on other themes easier, as I tend not to use them for that reason.  I use mainly default theme with different colour schemes as I don't have time to mess around with it.

[Rozak]

But degrading the theme system to make it more "easy" to adjust, will not happen. Thats crippling a very powerful and good feature in which SMF really shines.

Actually I'm not sure its about 'degrading' the theme system - and I certainly don't think its about 'crippling' it - strong words. It's simply about introducing an abstraction layer that is a little more robust than the one that is in place today.

I mean that could actually be as simple as moving some of the array definitions out into seperate files and pointing people at those to mod, or insisting that the language files in themes are maintained correctly (rather than theme writers installing lines into the core files or into the default language files, or into their own mod specific files) etc etc. The certification process that is in place already can be used to validate that.

I actually dont think this is something that is 'broken' in that respect - just a suggestion for an improvement. I also don't think it is anyone's 'fault' - and in fact most of the issues I've seen in my (small) exposure to the wonderful world of multiply theme'd SMF sites the issues tend to arise from over-generous mod hacking around inside all sorts of places in the code and non-comformant theme source. There is also the issue of varying levels of programming consistency/capability between mod and theme authors to content with.

The only point in raising this here was to say, basically, flicking through the forums, reading people's comments, playing with SMF - the largest cause of 'posts' and 'pleas' for help relate to the mod v template system and that there are a couple of ways of improving that - additional comments in the source will help (rather than having to mod against lines of code that may change from version to version of SMF or indeed if mod authors themselves have changed lines), an abstraction layer to isolate 'often mod'd sections of code' may well be a big job but would also go a long way to reducing the number of 'help me' posts.

I personally don't think that is a 'crippling' issue - but Bloc you are the developer here and for that I take my hat off and respect your opinion. I'm just a guy with more years of kernel programming behind me than I care to remember. Having seen the benefit of architectural seperation and abstraction in large code bases in environments where source code release is on a grand scale and co-operative development is the key to rapid but controlled incremental change - I merely put it forward as a suggestion for consideration. PHP application deployment is not my area of expertise - kernel development and management is - they are two different problems but there may be common lessons.

[bloc]

I hear you. The need for some more abstraction is def. needed and we are looking into the best way for it to happen. Initally it could mean to separate more common parts into functions. As modding around a function call is easier than trying to mod around the actual(most likely changed) code.

[Rozak]

100% agree

[d03boy]

I personally think there should be interfaces (functions instead of messing with context variables) to work with and maybe an "observer" pattern here or there. That is only talking about using the SSI though. I've never made a theme.

[Rudolf]

The comments are there to hang code to them. They are not always smart and don't always say clearly their purpose, but I used them to hang code to them.
The problem is that when you need to modify some existing code, comments won't help you at all. There will always be people who will get stuck when trying to apply code manually. I use comments around my code in my mods. Those who can't figure out how to apply the changes I made to the default theme to their custom theme, extra comments won't help them.

I think one nice thing would be if the Package manager would at least try to apply the template changes to every theme on the forum. It could be an option.
I think the biggest challenge is how to let the user know which themes failed, without failing the whole installation.
A long time I was thinking about this.

[JayBachatero]

Well DE tries to install the mods in every theme.  If the test are successful it will install on that theme.  If not it will skip that specific one.

[Joshua Dickerson]

Thanks for the suggestions. I would too like to see more places to "hang code." And language strings should be placed in 'modifications.[language].php'.

Rozak: what do you mean by an abstraction layer? I am familiar with the term, but where would we use it? If you mean that we should be moving more towards a MVC structure, I just want to let you know that is a goal of the development team.

[Rozak]

Rozak: what do you mean by an abstraction layer? I am familiar with the term, but where would we use it? If you mean that we should be moving more towards a MVC structure, I just want to let you know that is a goal of the development team.

It's about restructuring the internal architecture of the code to use a layer of indirection - either through something like arrays of function calls that can be used as calling vectors or perhaps using a fairly basic (but more structured) naming convention for function calls in the same way the template system essentially operates, or even using a more explicit file/include mechanism to split out the 'often modded' code areas.

A (very) trivial example might be by looking at the construction of actionArray in the top level of /index.php. Most mods go messing around inside there to add their calling functions to the array - essentially it is the main switching point for SMF. A (very) trivial change might be to split this definiton out (either by file/include structures or through a second level of indirection through a constructor function/vector) to make it easier for people to add entries to the array. Rinse lather and repeat for the permissionList arrays in ManagePermissions.php - another healvily mod'ed area.

The principle is to make it essenitally a 'dont' touch the core code' to add a mod that does the 'common' tasks (adds a tab, adds some permissions etc).

Not sure how familiar you are with file system code inside UNIX kernels but go look at the development of the VFS abstraction layer for a neat (but much more complex) example.

A more simpler process might be to follow a similar example to the rc/init.d type process. There additions to the operating system are dropped into known locations and scanned for at start up - it should be fairly simple to have a 'mod' directory inside SMF where mods can be dropped and either replace or are loaded into core code calling paths - certainly would be a lot less work to introduce a layer of abstraction.

Without knowing too much about what direction you guys are headed (and I certainly don't want to get in the way!) difficult to explain (oh for a whiteboard right now!) - but hopefully that gives you some ideas?

[bloc]

I am in fact experimenting with a new theme where I done some extracting. For example..consider this new code:

Code Select Expand

</head>
<body>
<div id="frame">
<div id="uppersection">
<h1>' , logo() , '</h1>
<div id="user">' , user_section() , '</div>
<div id="site">' , site_section() , '</div>
<div id="navigation">' , template_menu() , '</div>
<div id="linktree">' , linktree() , '</div>
</div>
<div id="mainsection">';
}

function template_main_below()

It will actually move whole sections into functions, making it easier to both radically change the html and mod this easily, as it can ideally just search for the function calls - or the functions themselves. Of course the smaller functions will need html code that allow it to be changed with css easily - so the user don't need to touch the function at all. The calls should be on separate lines though.

[Rozak]

exactly the right sort of thinking - you can even split out the php into files so the hook at the top, say, includes the function defintiions - that way more of the code is protected.

Looking at the way the template system works and restructuring templates in this way actully will go a million miles towards making the mod process simpler.

[bloc]

Yes..well, they won't be gone from the templates, that will in fact limit the theme system a lot, but since they will be separate parts of the same file instead of mixed, the mods can easier target the calls and place their changes. Not to mention ease the theme makers job lol.

Note that this is more of an test-project though, the actual theme system is under development of course, but not quite as dramatic. More use of css and getting rid of a lot of nested tables is number one pri there now.  

[Rudolf]

The main action when creating a mod is to search for an existing text and add something or replace it after.
Searching in one file or the other makes no difference. The more layers you put the harder it is to figure out where I need to change something to get the effect I want. Right now there's already a lot of layers - take for example the user info stuff. First a function loads it from the database, and creates a variable. Then another function fills another variable with basically the same stuff with a little more "formatting". This makes adding an extra profile field a bunch of work - you have to change a lot of things in a lot of place.

I am for a structured programming, and for separating content from presentation and wrapper functions and stuff, but there's a point when it becomes too much.

[Rudolf]

Take for example the template_menu() function in the Theme.
It's only useful purpose I can see for it is to find easier where the heck the main menu is "rendered", and it's easier to move it around (the menu itself).
When trying to modify the main menu the work for a mod creator is the same as it if would be written inline (where it is called).

[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.

[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.

[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]

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]

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... 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]

How 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.

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.

[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.

[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.

[Joshua Dickerson]

The same can be done with procedural. See MVC architecture. That is the architecture that the developers are working toward.  

[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.

[Dannii]

... 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.