User tests: Successful: Unsuccessful:
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
i was asking myself the same thing without a quick answer
but the fix is so easy so ...
Fixing code is easy. If we don't understand why things are getting broken, all we're doing is hacking around things. Is this indicative of another issue that's just going to be ignored by changing a line of code in a class that has had no meaningful change in months (years?) or just a long standing bug that never exposed itself?
Fixing code is easy
sometimes is not
not sure i'm able to answer your legit question, but in this specific case the "hack"
should be not "harmfull" .... at least
I don't think it's harmful I'm just annoyed with continuously seeing fixes for things that randomly broke and nobody can explain why it's broken. Understanding why something is broken by changes in unrelated code helps make sure the same types of problems don't come back later on.
I can't confirm exactly why was this happening.
But it's a page with lots of components. I'm using the template and components from RocketTheme: RokSprocket, RokGallery...
Logging the _observers
array, from that method, it got huge! In some way, a circular reference happens in the comparison with the handlers
I have tested this item
Despite #19912 IMO this should also be merged.
I was wondering if this is a correct fix.
I had approved because it resolved the issue and the error wasn't being displayed anymore. It was even the change I was made on my local code before opened the issue.
But, as in http://php.net/manual/en/language.oop5.object-comparison.php, the identity operator checks whether objects refer to the same instance, that is, if they are in the same memory location, without looking at the values of the properties.
And I don't know if this is the expected behavior in this case...
Am I getting it wrong?
I applied the #19912 and undid #19907 and the error isn't being displayed (maybe correcting the issue).
If I'm understanding this correctly then yes, it would be a valid change.
class TestObserver
{
private $db;
public function __construct(JDatabaseDriver $db)
{
$this->db = $db;
}
public function onAfterDispatch()
{
// Do stuff
}
}
Right now, if I tried to attach two instances of this observer to the event dispatcher, if the two observer instances are holding a reference to the same database object then the dispatcher won't add the second observer instance because it will consider it already attached. With the strict comparison, the two separate instances will attach to the observer because it is indeed two separate objects.
I can see why we have the code to try and prevent duplicate observers in the dispatcher, but it isn't necessarily a major issue to allow it either (at worst it would just result in a method being called multiple times).
I have just added the test by @Magisdn
Status | Pending | ⇒ | Ready to Commit |
RTC
Link to related topic on the forum https://forum.joomla.org/viewtopic.php?f=710&t=960132
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-25 14:55:40 |
Closed_By | ⇒ | mbabker | |
Labels |
Added:
?
|
Considering the event dispatcher hasn't changed in a long time, I'd like to know what's actually causing this issue.