Symphony.

Has anyone ever wanted to overload the getSource() method in an event?

Custom events could be much more powerful if we were able to generate the source dynamically.

It' a function, jut like any other, so if you wanted to you could. As long as it returns a number, relating to a section that the fields relate to...

It's static, which means it's called without initiating the class. In other words, you can't do much.

But it's static in the event your creating, which means you can do what you want with it in that event, right? I've just looked through the source code and I can't see it anywhere being called in a static method other than self::getSource() in event.section.php.

I'm still getting my head round this static stuff, does that mean it's not changeable?

Well, a static method cannot interact with the rest of the methods unless those methods themselves are static.

I would love to do something like this...

    public static function getSource(){
        if($this->section == 'item') {
            return '16';
        } else {
            return '15';
        }
    }

Where $this->section would change based on the code in __trigger().

Would it make sense to change this from a static method? I think it's only referenced in event.section.php, so it wouldn't be a difficult change...

I think making it static was a pretty recent change. I think we'll need Brendan to explain the reason behind it.

It was changed from memory to prevent having to create an instance of the Event object in certain areas around Symphony (ie. EventManager->listAll()). I think it was also largely a consistency change as the other methods of the Event class were all static, so it seemed unnecessary to create an Event instance just to call the one method (and costly in some cases I'd imagine)

You could still get around this at the moment by setting $this->section to be static as well in your __trigger() method.

@designermonkey Static stuff rules. It means that the methods you are calling is generally a black box, in that you put value $x in it and always get $v back. Static methods should rarely rely on class variables to work, unless these are static also (which is generally how it works anyway because calling a static method without having the object initialised results in an error when using $this->). Static methods are faster, easier to unit test and just generally make sense. I would love to rid Symphony of this $this->_Parent and switch all Managers to be static. The concept of needing to carry around the parent object isn't needed, and it's a pain in the ass to be blunt. In fact, deprecating $this->_Parent and introducing Symphony::Engine() was the first step down this path :) The PHP Manual is always good for more background about static too

I would love to see al the Parent stuff go too, debugging would be so much easier to find what I'm looking for, rather than trawl through all the back references of the same stuff... (at least I think it would?)

Awesomeness, self::$section works perfect.

I don't know why but for some reason I was thinking that a static variable would not carry values from one method to the other.

I agree on the $this->_Parent stuff, never been a big fan of it either.