Comments (4)
I can see how that'd come as a surprise - though in this case I think it might actually be a good thing. The more I wrote mixins the less I used clobbering functions. A function that clobbers goes against the whole idea of composing. If somethings a clobber it should really have been put on the prototype. The issue is that an after doesn't return it's value so if this was changed then the mixin would behave differently depending on the object you put it on, which is not what we want. It's better to have that "clobber" in there and know what is going to happen (although I would really recommend putting it on the prototype or making it an around so you can return the new value and keep whatever was there, something like:
around: {foo: function(fn) {fn(); return "My foo result";} }
from backbone.advice.
I don't want to use clobber; I want to be able to specify a function name in the mixin, that's not expected to be found in the target class, and have its return statement work.
If that function does already exist, I'd say it should throw an error at the developer, and allow them to provide mixin options indicating how they want the conflicting function to be resolved, e.g. { clobber: "conflictingFunctionName" } or { before: "conflictingFunctionName" }.
WDYT?
from backbone.advice.
"after" is the default but it's not meant to alter the return value, just run something afterwards. In the case where you want to have control of a return value then you should always use "around". If you're using around then you have control of the return type and the function that gets passed in so you won't have the issue.
I think the problem here is that it may be tricky to realise when to use around/after and which is the default. Do you think it would help if there was something about when to use each one and best practices in the README?
from backbone.advice.
I understand if you have an attachment to the current default behavior or
even if it's politically difficult to contemplate a change, considering
other client code relying on Backbone.Advice.
That entirely aside, I rather think the behavior default is surprising and
wrong, and not a good thing by any stretch of the imagination. By
specifying a name at the top level of the mixin (no options), the author's
intent is, I would wager over 90% of the time, "I don't expect this
function to be a problem" and "I expect my return statement to work".
Having to add "around" to get a return statement to work is a smell.
If you can't actually change the behavior due to other factors, I
understand. I believe that objective evaluation leads to the perspective
I've shared. I love clean code and appreciate the separation of concerns
and code-sharing enabled by Backbone.Advice, and I thank you for sharing it
regardless.
On Wed, Jun 11, 2014 at 1:16 PM, Rhys Brett-Bowen [email protected]
wrote:
"after" is the default but it's not meant to alter the return value, just
run something afterwards. In the case where you want to have control of a
return value then you should always use "around". If you're using around
then you have control of the return type and the function that gets passed
in so you won't have the issue.I think the problem here is that it may be tricky to realise when to use
around/after and which is the default. Do you think it would help if there
was something about when to use each one and best practices in the README?—
Reply to this email directly or view it on GitHub
#14 (comment)
.
from backbone.advice.
Related Issues (9)
- Tests don't run with latest version of Karma, tests fail on old version of Karma HOT 4
- Allow addToObj to accept a function that return an object HOT 1
- Monkey patch Backbone.extend for better syntactic sugar? HOT 2
- Mixed-in functions can't return values HOT 1
- "Backbone.Advice" object availability check. HOT 2
- Add to bower HOT 3
- Possible 'strict
- Possible 'strict' violations HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from backbone.advice.