Jump to content

IPB 3.0 Bold or not?


Guest Jaggi

Recommended Posts

not forgetting ipb 2.3 is still a great product so if they don't want to update to php5 they can continue to use ipb 2.3 so its not like the customers lose out too much because at the end of the day it comes down to them and how they want to go about it.

Link to comment
Share on other sites

  • Replies 80
  • Created
  • Last Reply
  • Management

IP.Board 3.0.0 is being developed with PHP 5.

It's a fantastic step up in OOP coding and I'm making full use of static classes for singletons, interfaces for APIs and factory classes.

My main aim is to eliminate $this->ipsclass completely so we don't have to manually pass it around to each script. This will remove a huge overhead.

It does make for some very odd looking code, though:

{ IPSDB::get()->build_query( array( 'select' => '*', 'from' => 'topic_markers', 'where' => "marker_member_id=".IPSActiveMember::$member_id, ) ); IPSDB::get()->exec_query(); while( $r = IPSDB::get()->fetch_row() ) { IPSClasses::get('forum_functions')->forum_by_id[ $r['marker_forum_id'] ] = isset(IPSClasses::get('forum_functions')->forum_by_id[ $r['marker_forum_id'] ]) ? IPSClasses::get('forum_functions')->forum_by_id[ $r['marker_forum_id'] ] : array( 'parent_id' => 0 ); IPSClasses::get('forum_functions')->forum_cache[ IPSClasses::get('forum_functions')->forum_by_id[ $r['marker_forum_id'] ]['parent_id'] ][ $r['marker_forum_id'] ]['_db_row'] = $r; IPSClasses::get('forum_functions')->forum_by_id[ $r['marker_forum_id'] ]['_db_row'] = $r; } }

if ( IPSData::$settings['db_topic_read_cutoff'] and IPSActiveMember::$member_id )


















Link to comment
Share on other sites

Excellent. :D

So will we have a nice IPB object model to play with in v3? ( e.g. all forum data accessible through a forum object, member data through a member object, etc. )

Link to comment
Share on other sites

i wouldnt doubt if IPB used 1meg of space just for $this->ipsclass :whistle:

so does this confirm that IPB 3.0 is "under way" :wub:

if this does confirm it. Matt you better watch out. gonna have alot of fans/stalkers :wub:

Link to comment
Share on other sites

  • Management

Excellent. :D



So will we have a nice IPB object model to play with in v3? ( e.g. all forum data accessible through a forum object, member data through a member object, etc. )



That's pretty much the aim.

It's still early days, but I'm splitting up $ipsclass into its logical components. For example, stuff like "ip_address", "user_agent", "browser", "session_id", "last_click", etc were just scattered around $ipsclass. These are now all variables within "IPSActiveMember".

The same with $ipsclass->input, $ipsclass->vars, which are now IPSData::$input and IPSData::$settings respectively.
Link to comment
Share on other sites

  • Management

E_STRICT:

"Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code."

It whinges about a few things, such as trying to access a static variable with a class method, etc. It's good for those hard-to-track bugs.

Link to comment
Share on other sites

E_STRICT:



"Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code."



It whinges about a few things, such as trying to access a static variable with a class method, etc. It's good for those hard-to-track bugs.


Thanks for that Matt. Sounds good all ready. :)
Link to comment
Share on other sites

if people really insist on wasting IPS's time by coding for a dying system (PHP4) i think is more than logical and fair to charge like a "php4 driver" type thing... 2 fully separate downloads. so that the php5 version has no bloat from anything php4 would need...

so if a guy wants to use php4.. he can pay 75$ for an entirely different version that is php4 capable.. thats how i feel. its like asking microsoft to make IE7 work on windows98...

Link to comment
Share on other sites

IP.Board 3.0.0 will not be compatible with PHP 4 and we do not have plans to make it so.



The advantages of PHP 5 are far greater than just singletons.



I'm glad to hear that IPS has made this bold move. It will be better for you and for the rest of us developing with it. I'm not so keen on the usage of static classes and calling for core functionality, as this doesn't really follow true OOP. Instead it more moves us back to the days of IPB 2.0 and lower where many classes had to be initiated and called upon separately from the core object (which actually makes things a bit more difficult). Abstraction to static, callable, classes at lower level processes (read, not application level. ie. mail parser) is one thing. Calling core (common) methods through static calls is going to be a PITA.

Maybe we can talk sometime about a similar deisgn I've been working on for a "kernel" over the past few years (and has settled down a lot in the past year). It uses the same sort of idea you are using, but keeps the OOP similarities you see in the current IPB.
Link to comment
Share on other sites

sounds good, nice to see you go php5 and that code snippet you posted is interesting not too sure about factories, read up on them but never actually used them, will look into it more specially since digi is raising some interesting topics.

Link to comment
Share on other sites

  • Management

I'm not so keen on the usage of static classes and calling for core functionality, as this doesn't really follow true OOP. Instead it more moves us back to the days of IPB 2.0 and lower where many classes had to be initiated and called upon separately from the core object. Calling core (common) methods through static calls is going to be a PITA.



No, that's incorrect. Using static classes as singletons makes things much easier. The whole point of a static class is that you don't need to initiate an object. You just require the class file and start using it; anywhere in any file after it's been loaded. You don't need to maintain an object handle and pass that handle around.

So, for example, in init.php you have:

# Load static classes: IPSData, IPSText
require_once( 'staticClasses.php' );

and in 'forums.php' you have:

print IPSData::$input['forum_id'];

That's got to be easier than:

require_once( 'ipsclass.php' );
$ipsclass = new ipsclass();

require_once( 'forums.php' );
$forums = new forums();
$forums->ipsclass =& $ipsclass;


For these static classes, you don't need OOP functionality. They are just a collection of simple methods that don't need extending or re-using in other methods. They are just grunt functions.
Link to comment
Share on other sites

No, that's incorrect. Using static classes as singletons makes things much easier.


That's your opinion on it. Remember you are "in the begining phases". If you think core classes like ipsclass are bad in IPB now, wait till you have a crap load of classes that need to operate together under multiple interfaces.

The whole point of a static class is that you [b]don't[/b] need to initiate an object.


Technically, you do in your examples. For a singleton, at least one time you must call that init() function. Sure you can call it multiple times (since its a singleton and all) and not have issues, but you still have the same sort of overhead that you would by using a proxy method to pass core functionality around.

You just require the class file and start using it; anywhere in any file after it's been loaded.


Lots of wonderful things can also be said about the overhead coming from using "require/include_once".

[font="Courier New"]


$ipsclass = ipsclass::init();


$ipsclass->doSomethingHere();



$forums = forums::init( [/font][font="Courier New"]ipsclass::init()[/font][font="Courier New"] );


$forums->doSomethingHere();


[/font]



Went ahead and corrected it for you. Technically you probably want a better way to get the ipsclass initiated object, but this, for all intents and purposes, serves to show my point. Further, if you load these classes from a centralized location, one would never have to care about trying to include a file or initializing a class. Not only that, but it gives a common interface for initiation/requesting the functionality.

Small example:

class ipsclass {


__get( $name )

{


... load requested class ...

}


}


class forums {


__construct(){


$this->ipsclass = ipsclass::init();

}


}


$ipsclass = ipsclass::init();

$ipsclass->forums->dosomethingHere();



This functionality allows for easy extension throughout the class hierarchy too, using the same idea of self initiation. MUCH easier, both to maintain and use, than calling static methods through pre-initiated static classes (which is bad practice to begin with) and public properties. This is a very simple example though and could be done much better than I've shown. :)


For these static classes, you don't need OOP functionality. They are just a collection of simple methods that don't need extending or re-using in other methods. They are just grunt functions.



That's not what you are using them for, and you actually did call it "OOP" in one of your previous posts. I said in my previous post that low level processes (like running a filter on an incoming data field) are great for things like this. From the examples you've shown, you have replaced the application level processing with static "grunt" functions that are actually still within classes that must be initiated. You are also calling class properties from static context, which is just silly because that means that all of those members are going to be public (bad design). So what's the point here. The purpose of static methods in classes (or static classes) is to reduce the overhead related to initiating a classes when the need for an actual object isn't there. You aren't doing that.

When you try to extend on these to work together, you'll see the error of your ways. I've already been down that road in my development and saw the same problems. A singleton design is not a static class (which you should always access statically). It's a method of initiating classes that disabled the ability to initiate, clone, or otherwise create a new instances of an already loaded.

I'm only posting because I don't want IPB to become a jumbled mess :P
Link to comment
Share on other sites

  • Management

I think you need to read up on static classes in PHP 5.

For a singleton, at least one time you must call that init() function.



You may have done in PHP 4, but not in PHP 5.

Not much that you posted makes any sense at all.

$ipsclass = ipsclass::init();


$ipsclass->doSomethingHere();



$forums = forums::init( ipsclass::init() );


$forums->doSomethingHere();



What has that got to do with anything? Why are you doing that? How can you correct my code without even seeing it?

Also, why are calling "init()" who says there's an init in my code? Why are you assigning a static class to a variable? And then use that variable as an OOP handle? That makes literally no sense to me.

ipsclass::method();



It's that simple. Trust me, 75% of IPB is now using it.

Here is code directly taken from IPB 3.0.0's "index.php" file:

{ require IPS_ROOT_PATH . "conf_global.php"; } /* Load static classes */ require IPS_ROOT_PATH . "sources/classes/static/core.php"; require IPS_ROOT_PATH . "sources/classes/static/member.php"; /* Set up DB library */ IPSDB::set( IPSData::$settings['sql_driver'] ); /* Load Cache */ IPSCache::load_all(); /* Parse Incoming */ IPSData::init();

if( file_exists( IPS_ROOT_PATH . "conf_global.php" ) )

















And here's some code from 'boards.php'
Note: no set up has been done, no variables passed around. All static classes are available *everywhere* instantly, like magic:

IPSDB::get()->exec_query();

IPSDB::get()->build_query( array( 'select' => 'id,description', 'from' => 'forums', 'where' => 'id IN('.implode( ',', $need_desc ) .')' ) );



And you can't tell me that's not going to work, because it is!

From the examples you've shown, you have replaced the application level processing with static "grunt" functions that are actually still within classes that must be initiated.



No, those were factories. They are a static interface to a dynamic protocol. Mainly so you don't have to pass object handles around for classes which you want available everywhere (session, display, etc)
Link to comment
Share on other sites

What has that got to do with anything? Why are you doing that?[b] How can you correct my code without even seeing it?[/b]


if( file_exists( IPS_ROOT_PATH . "conf_global.php" ) )

   {

	   require IPS_ROOT_PATH	  . "conf_global.php";

   }


   /* Load static classes */

   require IPS_ROOT_PATH . "sources/classes/static/core.php";

   require IPS_ROOT_PATH . "sources/classes/static/member.php";


   /* Set up DB library */

   IPSDB::set( IPSData::$settings['sql_driver'] );


   /* Load Cache */

   IPSCache::load_all();


   /* Parse Incoming */

   IPSData::init();




Even with this snippet of code from index.php, you still cannot judge how the classes are implemented. I haven't made any comments on any of the coding methods used yet, because I haven't seen the code yet.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...