Skip to content

?-operator not working for call to prototype-parental-method #3436

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
joehannes-zz opened this issue Mar 27, 2014 · 10 comments
Closed

?-operator not working for call to prototype-parental-method #3436

joehannes-zz opened this issue Mar 27, 2014 · 10 comments
Labels

Comments

@joehannes-zz
Copy link

hey!

today I tried to call super?().more...

it fails, because it actually compiles differently than a normal method check, please have a look, I honestly think it is a bug

cheers, Joehannes

@jashkenas
Copy link
Owner

Not quite. super is a keyword, not a reference to a function — perhaps foolishly, but them's the breaks.

@joehannes-zz
Copy link
Author

Mr Jermey, @jashkenas !

I dearly admire your work, and really and honestly just thought I do it way too much, but that's for me not wanting to have idols at all and trying to find my balance in everything.
Back.

Apart from that, would you be able to rethink your decision and consequently work on this?
As you of all people probably know ... super is not only a keyword, but also a reference to the same method down the prototype chain.
Therefore super?() isn't behaving as it should by all means of clean compiler design.

If you agree ... I'm happy, so please say so.
If you want things to stay like they are ... hmmm, I guess you're loosing personal fan-bonus points, but that's not gonna bugger you much probably.

So, show me some attention or respect the positive will to contribute to this wonderful tool of yours, coffeescipt ... come one, it's a mistake, why not change it? It wouldn't even break anything.

I feel a bit annoyed.

Cheers, Joehannes

@jashkenas
Copy link
Owner

If you'd like to read all of the conversation about why it is the way it is, search for previous tickets ... like this one:

#2638

Unfortunately, it would be a highly breaking change to change it at this point. Anyone that uses the super keyword without arguments would have their code break.

@michaelficarra
Copy link
Collaborator

I recommend avoiding the use of super entirely because of its syntactic inconsistencies and poor/inconsistent/implicit semantics.

@joehannes-zz
Copy link
Author

@michaelficarra can you also provide an alternative?
@jashkenas
OK, I guess you know it better than me, after all ... you created this tool
Also, I'm not sure about my good intentions anymore, so forget it if you choose so ..

Just to add a little spice ...
I can't see why it would break anything adding different behaviour to super?() or super? arg, arg2, ...
This is discernible behaviour.
Also, I have just found a different buggy implementation issue with super:
Trying to iterate over the methods of a class to see if down it's prototype chain is a certain method or not ... so as to avoid the first issue I run into yet other unexpected behaviour:
Using sugar.js I write:
Object.any(super, "observed")
and to my surprise it compiles to ...
Object.any(a.super.b.apply(this, arguments), "observed");

... the function again?!

OK, Cheers, good evening, I try to respect your choice sire, and hope you choose wisely

@epidemian
Copy link
Contributor

@jashkenas, i understand why changing this would be very cumbersome. But, if the general consensus is that super should behave differently, couldn't this be fixed on a major version update? As far as i can see, this is a syntactic change that could very well be automated: maybe we could provide a tool coffee1to2 (or 2to3, or whatever) that simply rewrites super to super arguments..., leaving no bare super reference (this assumes that the new super semantics would match LiveScript's, which i'd personally prefer).

On a more general note: i think that the tendency of programming languages to accumulate cruft and quirks over time for the sake of maintaining backwards compatibility could be mitigated if language implementers provided automatic ways to update when backward-incompatible changes need to happen.

What do you people think?

@michaelficarra
Copy link
Collaborator

@joehannes: Be explicit, invoke the constructor without using the word super.

@epidemian: I completely agree, and this is the reason I have avoided implementing super in CSR. I know it will eventually change to sane semantics, and when it does I will implement it. I'm personally in favour of matching ES6 semantics for any feature we have in common with it (kind of like we did when initially developing the language), but that's a much larger discussion.

@jashkenas
Copy link
Owner

@epidemian Sure, we can do it in a big update. It would be very nasty, because your old code would still be syntactically valid, but would now simply fail to call the function you were previously depending on calling ... and not even necessarily give you an error right at that point. It may fail mysteriously later, due to the lack of a side effect.

If y'all think that sort of nasty change is worth getting rid of argument-less super for, then feel free to open a PR...

@vendethiel
Copy link
Collaborator

Maybe we could, to give users time to upgrade, detect that super is not part of a call, and error on it.

@michaelficarra
Copy link
Collaborator

That sounds like a good plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants