@alex7r Please see alex7r#3

What's your use case for this. I'm hugely nervous of extensions disabling other extensions...

Background
For example I have an object that can have one role or another:
User can be client, team member or team leader.
Role functionality implemented by observer because we know which role user have only depending on data that were loaded to user object.
We don't want to pull everything once again from data base and create new object, we can attach observer that corresponds to user role.
It's all working great.

Problem
But if team member becoming leader we need to apply leader observer instead of member. So detaching observer would be nice.

Also I don't quite understand your vision on this, as I attach observer to JTableExtender instance and how can I access same instance from other extension? JTable::getInstance always returns new Class()

@wilsonge don't you agree, would it be merged?

@alex7r

if you want to detach observers added by your own extensions,

• then this should not be needed ?

because you can modify the code of the observer itself, to achieve what you need to do, right ?
even if your code looks less "clean"

@ggppdk
Sorry, but what you mean by this?
Can you provide working example which would not be hack for making something that should be essential?

I'll write a bit mess, but I believe everybody will get the point:

JTable{
public function attachObserver(JObserverInterface $observer)
    {
        $this->_observers->attachObserver($observer);
    }
}

TUser Object
(
    [_tbl:protected] => #__users
    [_observers:protected] => JObserverUpdater Object
        (
            [observers:protected] => Array
                (
                    [UserObserver] => UserObserver Object
                        (
                            [table:protected] => TUser Object
 *RECURSION*
                        )
                    [TUserObserverCoordinator] => TUserObserverCoordinator Object
                        (
                            [table:protected] => TUser Object
 *RECURSION*
                        )
                )
            [doCallObservers:protected] => 1
        )
)

So as you can see from all the above:
I can access $this->_observers
But I can't access $this->_observers->observers and iterate and unset as this is protected

@ggppdk you should be solid with

even if your code looks less "clean"

in this situation means

even if you reinvent the wheel

@alex7r

About accepting this feature, it is not my call,
what you need to do for this to be considered, is :

• prove / explain it is useful and common enough (i think you tried / done this already)
• convince maintainers it will not be misused or cause problems, that when such problems appear they will not have to run for it, to fix things

and usually "new feature" PRs wait for much longer time that "bug-fixes" PRs, i hope you are not disappointed with it, if you make a few 'new feature' PRs, eventually one of them will be accepted

again this is not my call

Just to reference my points once again:

#11037 (comment)

• prove / explain it is useful and common enough

#11037 (comment)

• convince maintainers it will not be misused or cause problems

@ggppdk , well I know and understand that it's not your call. I'm just don't letting you to impose fear and doubts on call-makers.

I'm just don't letting you to impose fear and doubts on call-makers.

you over-estimate my effects , anyway i understand

I believe if any one says that something like

It's not compatible

or

Well, is it needed?

it is a ring call for rechecking and doubting changes. And I also think that it's right position in terms of repo maintaining as millions are using this code and

with great power come great responsibility

So some explanation like why this way and not another and why it's safe is good thing.

Ok I think the use case is fine. Does this patch work tho? Just on code review (as on holiday) isn't the key the class name rather than the observer itself?

@wilsonge , yes it works.
May be I should have change var name, but I thought that 'key' is not the best Idea, 'classname' doesn't suite well, so I leaved 'observer'
But if you'll look at PHPDoc - @param String
and described as 'observer class name'

@wilsonge , @mbabker
Can any one with merge permissions take a lot at it once again?

Yes - but i'm holding on merging things until we're satisfied with 3.6.0 and are sure we don't need to make any quick follow up releases

3.6.0 is out, Still waiting )

Some status updates? @wilsonge

It looks to me that @wilsonge marked this as RTC but he did it wrong and the cms-bot removed the label. I will set it back to RTC now - it would not have gone in a 3.6.x release anyway as it is not a bug fix.

RTC

thanks