Objects

Nao

  • Dadman with a boy
  • Posts: 16,061
Objects
« on May 6th, 2011, 05:11 PM »Last edited on February 8th, 2013, 10:36 AM
Feature: Objects
Developer: Arantor (main), Nao
Target: modders, themers
Status: 95% (believed to be complete; there's always room for more objects though.)
Comment:

SMF uses the infamous $smcFunc array structure to store pretty much anything that should be dynamic functions.
Wedge replaces this with object structures, mostly of the singleton/static types. Basically, Wedge objects start with the 'we' keyword, generally followed by a three-letter code representing whatever feature it's about.
Some of the objects include: we (holds system and user variables such as we::$id for the user ID), wesql (database abstraction, e.g. wesql::query), westr (string functions, e.g. westr::substr), wecss (CSS pre-parsing), wedit (the WYSIWYG editor), and wetem (the main template skeleton).

Re: Objects
« Reply #1, on July 2nd, 2011, 07:49 PM »
Why are you using a singleton for a query? Using singletons everywhere is the same as using procedural.

Re: Objects
« Reply #2, on July 2nd, 2011, 08:31 PM »
there is still a benefit in using (static) classes: the visibility (public, private and protected)

Re: Objects
« Reply #3, on July 2nd, 2011, 08:50 PM »
And namespaces, too. I think.
I'm not very bright when it comes to objects.

Re: Objects
« Reply #4, on July 2nd, 2011, 09:54 PM »
No, it isn't. Namely, the connection holder can be kept within the object, plus you don't have to mess about bringing things back into scope.

Oh, and my register replacements setup. In SMF, the only way to add things like {query_see_topic} or any other such replacements, you either have to create a wrapper around the DB stuff (like SimpleDesk does for its {query_see_ticket} parameter) or modify the DB code to add them (as Project Tools does for {query_see_issue} parameter)

Now I have a singleton that contains all this, it has a setter method to handle these in a way that doesn't pollute global variablespace and is still available application wide without any fuss.

That, and it's faster than calling a variable function.

Re: Objects
« Reply #5, on July 3rd, 2011, 05:50 AM »
It is the same in the sense that it isn't object oriented. If all you're using a class for is a function wrapper, use namespaces.

Each query and each connection should be a separate object... because they are. Now, since you have all static methods, how would you work it if you wanted to have multiple connections? No clue how you are working queries, but what if you wanted to run a query in two places at the same time? You're going to have issues with coupling.

The query_see_topic and query_see_ticket stuff should probably be a method of that class. In reality, you should just worry about normalizing that table.

Re: Objects
« Reply #6, on July 3rd, 2011, 10:32 AM »
Database instance itself should always be singleton, queries can be a separate instance I guess, it is the method I followed when I shared by own code for DB hooking, although in that case I kept result in the query itself(Similar to how PDO does it).

Re: Objects
« Reply #7, on July 3rd, 2011, 12:07 PM »
Quote
It is the same in the sense that it isn't object oriented. If all you're using a class for is a function wrapper, use namespaces.
We're still looking at 5.2 as the minimum acceptable version, where namespaces aren't available.
Quote
Each query and each connection should be a separate object... because they are.
No, they're not. Connection, yes, query, no.

In any case, consider the structure that both SMF and Wedge use: they create a single connection for the persistence of runtime (as far as possible) and in SMF's case it's stored in a global variable. I've just attached that to the singleton because that actually makes more sense to me than using global variables. There is no need for it to be in global scope, nor any need for anything other than the singleton to access it - so there is more at stake here than just namespacing in another form, visibility is important too.
Quote
how would you work it if you wanted to have multiple connections?
Exact same way you do in SMF, if you really need to do that. The fact is, though, the occurrences of it are so rare it's almost not worth worrying about. And while you dislike it, it solves a number of practical issues for modders, namely having to worry about $smcFunc or its analogue being in scope - it "just works". They don't have to worry about the finer points.
Quote
it is the method I followed when I shared by own code for DB hooking, although in that case I kept result in the query itself(Similar to how PDO does it).
And that's probably how we'll move towards it being. Right now there is absolutely no need for it to be separate objects all over the show with scope and visibility being far more complex than they need to be.

Re: Objects
« Reply #8, on July 3rd, 2011, 05:49 PM »
In SMF you'd assign it to another variable. With a singleton you'd need another class.

Dragoon, like PHP, where you have that last parameter for the resource, you should have the ability to select the resource or use a default one. There's many good reasons for using different databases.

I'm not knocking using OOP over a global variable, but you should use what's right. So, instead of $result = we::query('SELECT * FROM some_table') consider $result = new weQuery('SELECT * FROM some_table');

It works the same but you have more ability. You then put a whole bunch more ability on to that: statements, fetching on the object, etc.

Re: Objects
« Reply #9, on July 3rd, 2011, 06:06 PM »
Quote
In SMF you'd assign it to another variable
You don't know SMF very well, then. Every single one of the $smcFunc DB functions supports passing the connection identifier to it as a parameter and using the global one if not provided. My singleton works the same way so I do not need another class.

Re: Objects
« Reply #10, on July 3rd, 2011, 09:31 PM »
I have to agree with groundup on his OOP stance here... (Probably not very suprising; I think I said something similar in another topic.)

Re: Objects
« Reply #11, on July 3rd, 2011, 11:01 PM »
wesql is what it is right now, that's the only claim that can be made of it. It was one of the first big things I did, and it was done the way it was done for a reason: breaking the cycle.

I never really expected it to be the final "this is how it will be done", but more than that I recognise the importance of moving. I've seen things killed by "analysis paralysis", where you spend so long staring at it, and tweaking the design, that you just end up never actually implementing it. I've even found myself hitting it more than I'd like so far and it's been the silent killer of my productivity.

So by making the change generally, it's the start of something bigger, rather than the destination in its own right...

Re: Objects
« Reply #12, on July 4th, 2011, 09:26 PM »
I agree. Better get started on big changes sooner with small things, than wait forever until everything is figured out. You can't make an omelette without breaking a few eggs.