When jQuery, Microsoft or some other software company says:"this function is deprecated".
For example, when there is a func1 that works fine in version 1.0 and is deprecated in version 2.0 that also introduces a new func2:
Should func1 also be included in version 2.0 for backwards compatibility?
Is func1 supposed to work without bugs in version 2.0? ( func2 is fine with versions 2 and 1)
Is func2 allowed not to work correctly in version 2.0?
What does deprecation really mean and does it mean the same in all organizations?
For ex. the live method in jQuery doesn't work in 1.7 in IE but it does in Chrome).
I think the Wikipedia-article on Deprecation answers this one pretty well:
In the process of authoring computer software, its standards or documentation, deprecation is a status applied to software features to indicate that they should be avoided, typically because they have been superseded. Although deprecated features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated—rather than immediately removed—in order to provide backward compatibility, and give programmers who have used the feature time to bring their code into compliance with the new standard.
Deprecated means they don't recommend using it, and that it isn't undergoing further development. But it should not work differently than it did in a previous version unless documentation explicitly states that.
Yes, otherwise it wouldn't be called "deprecated"
Unless stated otherwise in docs, it should be the same as before
No, but if there were problems in v1 they aren't about to fix them
If there are true answers to those questions, it would be different per software vendor and would be defined by the vendor. I don't know of any true industry standards that are followed with regards to this matter.
Historically with Microsoft, they'll mark something as deprecated and state they'll remove it in a future version. That can be several versions before they actually get rid of it though.
Deprecated in general means "don't use it".
A deprecated function may or may not work, but it is not guaranteed to work.
The simplest answer to the meaning of deprecated when used to describe software APIs is:
Stop using APIs marked as deprecated!
They will go away in a future release!!
Start using the new versions ASAP!!!
Related
I have had a hard time finding any project that uses the OpenMath standard and that's still maintained. A lot of libraries seem to have disappeared, to be undocumented or rely on dependencies nowhere to be found... and I'm a bit lost.
Are there projects actively using this standard? Is there any cooler standard I'm not aware of? I know there's MathML and OMDoc but the first doesn't hold semantic information like OpenMath and the second relies on OpenMath, so neither of them counts as an alternative.
I have also found more recent libraries like pyopenmath and openmath-js, but neither of them implements the whole standard and are not being further developed.
(I wasn't really sure what site to post this question in... so if you think I should move it to somewhere else please tell me kindly. Thanks. Already moven from Math stackexchange)
I struggled with this for hours before finding out that you have to use from_ instead of from when using gremlin javascript.
After digging through the source code I finally found out that the code is using from_ instead of from (see code). Since I'm a newbie this comes off as strange because its counterpart to is still to (and not to_, see code here)
I googled everywhere but couldn't find the reason why this works this way, and feel uneasy about using the underscore version since most of the times underscores denote private methods that users should not really trust.
Also, is there an official documentation page for gremlin javascript somewhere I'm missing? I'm concerned I may run into these problems in the future and there's not really an official documentation for the JavaScript version and I may need to go through the same struggle. I like gremlin, but if the JavaScript version is not stable and should not be used, I might as well look into other alternatives than Tinkerpop suites.
Gremlin Language Variants (GLVs) are given some latitude in terms of how they implement the Gremlin language so that it feels as close to the syntax and programming idioms of the native language and thus avoid too much pollution from Java. In other words, if you're using gremlin-javascript it should feel like your coding in JS and not Java. So, you will see slight differences among GLVs from time to time.
So, with respect to from_ specifically, we typically use an underscore when we have a conflict in a native language with a reserved keyword. In Java from is fully acceptable, but in other languages it is not. For Javascript, from is currently not a reserved word, but we are preparing for the eventual form of import ... from which is coming in the future.
As for documentation, I'm not aware of too much more than what you have already found on the TinkerPop web site. We hope to have more examples and information available in our next release.
I struggled with this for hours before finding out that you have to use from_ instead of from when using gremlin javascript.
After digging through the source code I finally found out that the code is using from_ instead of from (see code). Since I'm a newbie this comes off as strange because its counterpart to is still to (and not to_, see code here)
I googled everywhere but couldn't find the reason why this works this way, and feel uneasy about using the underscore version since most of the times underscores denote private methods that users should not really trust.
Also, is there an official documentation page for gremlin javascript somewhere I'm missing? I'm concerned I may run into these problems in the future and there's not really an official documentation for the JavaScript version and I may need to go through the same struggle. I like gremlin, but if the JavaScript version is not stable and should not be used, I might as well look into other alternatives than Tinkerpop suites.
Gremlin Language Variants (GLVs) are given some latitude in terms of how they implement the Gremlin language so that it feels as close to the syntax and programming idioms of the native language and thus avoid too much pollution from Java. In other words, if you're using gremlin-javascript it should feel like your coding in JS and not Java. So, you will see slight differences among GLVs from time to time.
So, with respect to from_ specifically, we typically use an underscore when we have a conflict in a native language with a reserved keyword. In Java from is fully acceptable, but in other languages it is not. For Javascript, from is currently not a reserved word, but we are preparing for the eventual form of import ... from which is coming in the future.
As for documentation, I'm not aware of too much more than what you have already found on the TinkerPop web site. We hope to have more examples and information available in our next release.
Some libraries, e.g. xml-rpc, directly use url-retrieve. I want them to instead use request.el, so that I can choose curl as my backend. Is there an easy shim-layer I can install?
I'm looking for something like curl-for-url, which transparently rebinds url-http with a compatible implementation. (curl-for-url itself doesn't actually work very well, though.)
You could do this using advice, but you will need to use the
ad-get-arg/ad-get-args functions to extract the arguments url-retrieve was
called with and determine how you want to process them and pass them to the
retrieve function. The one which will likely be problematic is the callback
function. However, provided you can setup the buffer with the downloaded
data in the same way, with the same name as url-retrieve, you should be able to
apply the callback manually after the call to request and you have setup the
buffers as necessary.
It will be a fair bit of work and you will need to dig deep into both the url.el
and request.el libraries. It is also likely to be a bit fragile.
One concern I would have is the use of monkey patching by request.el. From the
project page, it looks like this code has not been updated since Emacs version
25.1 and the current official emacs is 25.2. This is one of the problems with
monkey patching - you need to keep versions in sync to avoid version
incompatibility issues.
It also seems odd to me to have someone who has patches to fix known bugs if
those patches have not been applied to the mainstream version - especially when
there has been a more recent release of the mainstream version.
The first thing I would do is upgrade to emacs 25.2 and then determine if using
request.el is as justified. I would also verify the problems you experience are
actually due to url-retrieve or are perhaps due to callbacks being passed to
that function. If it is a problem with the callbacks, you may be better off
using advice to fix those callbacks rather than replace the underlying
problems.
If you only have issues in some situations where url-retrieve is used, it may
also be easier to go up one level and look at the things which are using it and
perhaps use something like advice to replace the call to url-retrieve with
request at that level.
Someone might be able to provide more specific recommendations if you provide
more detail on the precise reasons you cannot or do not want to use the
url.el library.
I was changing out some PHP code the other day because it was deprecated, and no longer worked. I understand the meaning of deprecated code based on an answer I found here: https://stackoverflow.com/a/8111799/1810777
But several question came to mind:
I was wondering what is the purpose of deprecating code?
Why not just leave it in use, instead of recommending others to use
new alternatives?
Does it slow stuff down?
I couldn't find anywhere else online that talked about it. I'm just really wondering why code that used to work well, isn't useful anymore. Thanks!
It means that in a future release it's going to be removed.
This allows an API developer to give people time to migrate to the new version / method of doing whatever rather than just pulling the rug out from under them. Both the new and the old versions are available for a limited time.
As for why not leave it there forever ... because there's a new, better way to do it. You can't support legacy code forever (if you value your sanity and your budget). All support has a cost (be that tech support hours, bug fixes, regression testing, etc)