-
Notifications
You must be signed in to change notification settings - Fork 321
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
Deprecation of last
in Xtend
#3187
Comments
I would be interested in contributing some solution along the lines of 1. or 2. myself, though I can't say when I might have time to do such a thing, and I'll definitely need some help setting up. The last time I considered contributing something to the project some years ago, I was immediately put off because there were many errors in the various projects after oomph finished setting up the workspace and the instructions did not seem to expect this outcome. |
@dpetroff I personally handled the issue about At the beginning, I was suggesting something along with what you propose. @szarnekow suggested instead to keep things simpler. Note that, if I'm not wrong, the precedence that was implemented long ago to new Java methods like In this case, single |
It's a curious case. One of the design principles was and is that neither Xbase nor Xtend will disallow accessing members that would be accessible the same way from Java. In that sense, an extension method must never shadow a member. This principle won't change since it will likely break many existing programs. |
I'm concerned that I couldn't find any discussion related to the commit here, and from my perspective as an Xtend user, this seems to make very little sense.
From the perspective of Xbase, I would not have thought that changing the semantics of Xbase libraries makes sense just because Java adds a method to
List
with a similar but actually different name (note theget
part in the Java version) and different semantics. I may be wrong since it was a while since I've used Xbase directly, but my understanding is that, in Xbase, extensions are opt-in and the extensions part of the Xbase library is provided as a convenience for language developers. In this case, it ought to be up to individual language implementers to choose how they deal with Java introducing breaking semantics.From the perspective of Xtend, the language is called Xtend, it's all about extensions as a core concept, and it never made sense to me that extension methods do not override object methods of the same name. I made peace with the last part because I can see how a breaking change that kills every Xtend project ever is not going to take place lightly.
Yet here we are, deprecating
last
because Java is unintentionally introducing this kind of a breaking change that I expected would never come from Xtend. Replacinglast
withlastOrNull
is not appropriate because the semantics of Xbase and Xtend iterables have always been that they do not throw exceptions. I can see how throwing the exception is technically correct and will cover the 0.5% of corner cases where that actually matters, but the semantics oflast
are already very niceI propose instead of accepting the breaking change coming from Java and deprecating
last
we pick one of the following better options:last
is preferred because the member method in Java is calledgetLast
and can therefore be explicitly referenced. This is by far the worst option because it relies on naming convention to avoid future intrusions from Java member methods. But it has the benefit of actually not breaking any existing code, so I figured it was worth mentioning.I submit for your consideration that as an Xtend user for nearly a decade, I find that there is realistically no use case for defining an extension method with the same name as a member method where the member method is preferred over the extension method. In my experience, the bugs have always come from forgetting that a member method already exists and expecting my extension method to be used instead. However, I propose that if the need seems significant, the
self
keyword may be reused to explicitly access member methods such assomeThing.self.memberMethod
when it's necessary, as unlikely as they may seem to me.The text was updated successfully, but these errors were encountered: