Wedge

I'm not fussed either way. I could rename plugin-info.xml to plugin.xml to be honest ;) I'm not that fussed, skin.xml is fine with me, just as skin-info.xml is.Long names *are* more readable, yes.I'm trying :)

Also...
WIZARD NEEDS FOOD BADLY.The sign of a true artist, continually evolving, striving to improve it all the time.

Okay, re: plugin-info.xml, to me it'd make more sense to have 'plugin.xml', but it's your 'area', so your preference matters more ;)

Regarding skeletons, I've been considering multiple ways of doing it these last few days, most of them 'unclean'.

So, the two that remain right now are these:
- the 'realistic' solution: wetem remains a singleton, but wetem::$skeleton becomes an array of skeletons. Same for wetem::$layers, etc. Has the advantage of being easy to transition. Can do wetem::render() to render the main skeleton, and wetem::render('message') to render a specific mini-skeleton. Drawback: not that it's necessary inelegant, but having a singleton to manipulate multiple objects can sound strange...
- the 'object-obsessed' solution: wetem becomes an actual object system, we'd then do $msg = new wetem('skeleton-message.xml'), or something like that. Then $msg->build(), then $msg->render(). Main advantage: it looks way better in the code... Main drawback: okay, I can't possibly imagine asking plugin authors to insert a global for $rootSkeleton (or something) and then call $rootSkeleton->add('sidebar', 'my_block') to add a block to the sidebar... This seems uglier to me than wetem::render('message').

I'm trying to figure out whether it's possible to have the best of both world, i.e. if wetem::render is called, then we automatically redirect to the $rootSkeleton object, and if $something->render() is called, render said object. I don't know whether that's possible right now... I could imagine storing the main skeleton inside its own static (or global?! meg...) variable, then relying on it if function render() doesn't find a qualified $this value. But, we'd have to do the same for add(), and so on...

So... Any opinions? I'm afraid I'm not in the best position to comment on object creation :P

Adding to the question.
Both solutions are complicated IMHO...

- Staying static sort of feels like I'm from a procedural world (which is true), and that I'm trying hard to remain traditional while giving the appearance of working with an object.

- Going half static, half dynamic probably means I'm going to have to duplicate a lot of functions... One for mini-skeletons, one for the main skeleton. (Which I'm tempted to rename internally to 'backbone', dunno why :lol:) And that could be even more confusing. Just look at wetemItem: I'd have to rewrite it to address both the 'backbone' and any other skeleton. Because right now it's just acting like it's one big static skeleton. I'll give a try to mixing static and non-static functions and see how they behave when called dynamically and statically.

- Going fully dynamic would be the way to go, but as I mentioned earlier, I would absolutely hate having to force plugin authors to declare a global for backbone/root/main manipulation. I've given them power with so many methods -- I don't want this to be at the cost of simplicity in their main code. And don't get me started with $_GLOBALS['backbone']->build()... Alright? :lol:

---

Okay, it was too hard on me, I decided to immediately try for a simple version of the dynamic/static test I mentioned. Here's the code I tried... Note that all the class and method names are French synonyms of the word 'thing' :P


I'm surprised that I'm not getting any crashes, or even any warning from PHP at this point..?!
This was done with PHP 5.3.4, downgrading to 5.2.9 gave me a 'parse error' crash on both $chose:: lines, meaning only PHP 5.3+ supports using a static call from within a dynamic object. Or something... More 'interestingly', $chose::$any_static_variable doesn't work in PHP 5.2.9 either, even though the php.net docs seem to indicate otherwise.

So, it seems there's something that... could be done, I guess... Regarding using 'wetem::add()' for the main skeleton and '$other->add()' for other skeletons without duplicating the 'add' function -- something like if (!isset($this)) $skel = self::$skeleton; else $skel = $this->skeleton...??
It still makes life complicated and forces me to rewrite all functions to use a pointer to the desired array ($skeleton, $layers...), rather than directly access self::$layers or whatever.

I'm still not much used to all of this... It's really not my initial area of expertise. I think it's important that I get it right on the first try, which is why I haven't developed anything so far.
Waiting for opinions and ideas, then...!

I may have found a solution...
http://www.php.net/manual/en/language.oop5.overloading.php#object.call

Basically, set all functions to be private. Calling wetem::add will invoke __callStatic, in which I'll first check through the list of authorized function names, then if allowed, redirect to that function while passing self::$instance as the instance, while $object->add will invoke __callStatic which does the same, but passes $this as the param.
I'm not sure it'll work... But it seems... possible?!

F*ck! __callStatic (not __call) is PHP 5.3+ only... -_-

Okay, there may be a possibility that it "just works"...


(Of course, I removed the 'private' keyword for $skeleton.)
The first print_r gives me the main skeleton.
The second print_r gives me 'DELETED'.
The last print_r gives me the main skeleton.

So, it would seem that wetem:: acts just like a regular instance of wetem, and keeps the data associated to it.
Which is pretty good. And means I wasted more hours trying to fix a problem that didn't exist in the first place... :^^;:

Now, the only issue is that E_STRICT supposedly should/would return a warning when calling one of these, because it doesn't like to mix static and dynamic stuff.. But it doesn't give me anything.

Oh, bugger... Forget what I said.
Inside the $a instance, $this->skeleton gives me DELETED, while wetem::$skeleton gives me the main skeleton. I should have guessed...
So it's back to the isset($this) test on each function... Or giving up and using arrays for every instance. :(

Anyone..? I hate talking to myself all day... :whistle:

Don't use magic functions, they're pathetically slow. Can't you simply declare static functions in a base class, declare a new singleton class for main skeleton extending the base which has calls to the parent class but also passes the first parameter and keeps everything sane? That or make a new class for only one skeleton (you need more than one?) which is singleton and has instance object to return the only instance that it has?

But.. THAT slow?
They're only called if the method isn't found.

I've been thinking it over last night, and figured out I didn't really need to have __callStatic...
I can simply implement __call, and then pass all the information about the current object to the static wetem object.
For instance, $message->build() would magically call __call(), which would then pass the data to wetem::build($message->id_object) or something. For instance, I could store the contents of the static object into a temp var, replace the static object's vars with the dynamic object's, call the static function, then replace the static object vars with the temp vars.
Of course it's going to be much slower... But we're talking about relatively small arrays. My only concern is with calling these things repeatedly... It'd be better, I guess, to have a dynamic object in the first place and __callStatic to bind the backbone to a dynamic object, because wetem we know isn't being accessed a lot. But we don't have that leisure, as __callStatic is PHP 5.3 only. Unless Pete wants to reconsider our minimum PHP version. But that particular use case probably wouldn't be enough to justify it...

Then again, we could also simply use arrays of arrays. wetem::$skeleton['backbone'], wetem::$layers['backbone'], things like that...But that's pretty much like one of my first suggestions, duplicating everything...?
Well, now I guess we could hmm... Well we don't have that many public methods in the object in the first place, that's true.

(I also liked having the 'final' keyword on wetem... It's the only time I ever used it, and because I use it in Class-CSS, it sounded cool to also have it in a proper PHP class :lol:)But it would thus require to do wetem::getInstance() every time we want to access the main skeleton. To me, it's exactly the same as doing a global $backbone thingy... Isn't it?

I'd really like more of your input on this, as well as Pete's -- and anyone who's into OOP really. (Yeah, OOP, not the other word I used last time, remember Shitiz :lol:)

Benchmark them, AFAIK they're atleast 10-20 times slower than direct calls.You're not really duplicating, you're just making the child function call its parent.Maybe, but IMO getInstance is better. Simply because wetem::getInstance is more verbose than a global variable called $backbone, secondly as far as clean code goes we need not have it at the top of the function and can place it anywhere. That, and a jackass function can't overwrite it with it's own stuff.

Or here's another fun idea, make a base template class (dynamic, ofcourse) which is not a singleton. Then make a singleton class which is the main skeleton (extend it and make the constructor private and add getInstance), use it for the backbone skeleton and add a function in base class that can import full skeletons from an instance of the class to that class. This way a mod can do something like create it's own skeleton, and import it to the main skeleton.

I think this is the way it's going to go. ;)

wetem()->load() is unusual. It's fine, of course, but it feels unusual to write. wetem::load() would be better.

Oh, I have hundreds of tabs with dozens of topics open... 99% of which will never be closed!Plus I don't need to update the hundreds of existing calls... ;)There are no consequences whatsoever. The only things to think about are ease of use, and performance.

Performance is a big consequence to me as well as ease of use.

I don't really mind ease of use being changed provided it's not made insanely hard to use. The current setup is not that hard to use, which is fine with me.

I don't think there's a significant difference between a function call and a static method call.