-
Notifications
You must be signed in to change notification settings - Fork 9
Why is Modifier.modifier
necessary?
#7
Comments
@chancancode IIRC (because it has been so long) the documentation (lack of) specifically needed to call If you have a suggestion feel free to offer it. I by no means am an authority on Object Oriented Programming. I just feel passionate about OO because of amazing work from people like Sandi Metz, Bob Martin, Martin Fowler, etc. I would hate to see all that effort lost in a frantic Functional crazed ecosystem. Hence why I ran with this addon idea. |
Another way of putting it (I'm asking for help and guidence on this): I don't fully understand the question. I was under the impression that the Factory method pattern was a well established Object Oriented Pattern. According to the documentation at the time |
Yes I appreciate it, thank you for the work! :) Yes you would call setModifierManager on a class not an instance. However, if a manager is not found on the exported class (from app/modifiers/*.js), Ember will walk its superclass chain (prototype chain) until it finds one, or else it will error. Since, in your OO manager, everyone subclasses from the classes you provided, you can simply call that on your provided superclass, and every user written modifiers will have the write manager set. Technically, the exported value (from app/modifiers/*.js) doesn’t have to be a class, but nevertheless ember still expect that value or somewhere along its prototype chain has a manager set, that’s how we provide flexibility for things like functions. However, the OO use case is definitely the first-class one in our design, so you can take advantage of that and make the api less verbose for the users. |
I think the confusion comes down to a miscommunication here. How does a super class know what child is to be used in the I know I am missing some kind of meta-programming here but I don't recall which. Considering that the functional implementation was the only documentation at the time. Maybe an explanation on what I would love to remove the
Who calls I am really sorry for my misunderstandings. |
Concretely, I am suggesting that:
This creates a "subclass" of the The way this works in each class has a prototype pointer ( |
It was previously necessary to call Modifier.modifier on the exported modifier class. We can remove this requirement based on the input of @chancancode in #7. This commit implements the behaviour as we understood it from this issue. The deprecation message indicates version 1.0.0 will drop support for calling Modifier.modifier, this has not been discussed and is subject to change. The examples of the README have been updated to not show the deprecated Modifier.modifier call. The tests have been duplicated to contain both the calls with Modifier.modifier as well as those without. The tests have been updated mechanically with Emacs Macro's rather than being smart about them to keep the tests obvious.
It was previously necessary to call Modifier.modifier on the exported modifier class. We can remove this requirement based on the input of @chancancode in #7. This commit implements the behaviour as we understood it from this issue. The deprecation message indicates version 1.0.0 will drop support for calling Modifier.modifier, this has not been discussed and is subject to change. The examples of the README have been updated to not show the deprecated Modifier.modifier call. The tests have been duplicated to contain both the calls with Modifier.modifier as well as those without. The tests have been updated mechanically with Emacs Macro's rather than being smart about them to keep the tests obvious.
Now I understand the confusion. It would seem based on what you are saying is that we are not setting the modifier manager like the method name suggests but instead registering some kind of magical suggestion. This somehow does something that is not setting and the user's manager is used despite never having registered it but merely its parent class. I appreciate your explanation and based on PR #8 working this magic works. I'll go with it but I am still missing one key piece of information to understand it. |
If it helps you, the thing this is modeling is this: class Parent {}
Parent.manager = MyManager;
class Child extends Parent {}
Child.manager // => MyManager The prototype chain is just describing how this mechanism works under the good in vanilla JavaScript, but inheriting static properties are common and expected. The only reason a weak map is used instead of a property is (first and foremost an implementation detail) to avoid “polluting” the class when you look at it from the console or when looping through it’s properties. |
So the user has to do this? According to the above it is more like: |
After much discussion with @madnificent I think I finally figured out where my mental model was blocked. I going to re-iterate my understanding here for prosperity. First, this concept is based on the idea that duck typing is not used. This is where my mental model could not understand because I was hard pressed to think that if a ModifierManager quacks like a ModifierManager then it was a ModifierManager. However, if duck typing were removed from the mental model then there would be need to have some way to type check that a ModifierManager subclass inherits from a known ModifierManger. The chain of events is:
Even though Internally it uses a WeakMap to avoid holding onto references to Classes but the consequence of doing that is that Ember has to implement its own prototype walk and can not use I think this is how the world works. I hope. cheesy-grin |
This has been fixed in #8! |
The intent is that this addon will set it on the super class that your users extend from, and Ember will walk the class chain and find the manager. Is there some reason why that didn't work out?
The text was updated successfully, but these errors were encountered: