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)
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.
This question is inspired by the remark of Duncan Murdoch on the r-devel mailing list in response to a bug report about Sweave :
This is fixed in R-patched. (It would
have been fixed in 2.12.0 if more
people tested the betas...).
Honestly, I've stayed away from beta -aka development- versions for a number of reasons, and these are reasons I hear from more people :
I am a bit horrified it would
somehow cause conflicts with my
current R distribution. As I need it
for work, having to repair it regularly would be a loss of
time I can't explain to my boss
I wouldn't have a clue how to test
efficiently. I reckon every test I
could come up with has already been
run by the development team.
I still find it difficult to figure
out when something is a bug, and
when (most often) it is my own
stupidity kicking in.
But as I understood, it would be a valuable contribution to the R community, and I'm willing to do my bit of the testing as well if I can fit it somehow into my own work. I was thinking of keeping the beta on the side and running my scripts through it as well as a checkup. Saving the constructed objects allows a quick and easy all.equal() to see if something is wrong.
Anybody some more/better ideas on how I could help testing with a minimum amount of effort and a maximum amount of efficiency?
I'd also like to promote this a bit more on our department as well. Apart from the "It's time to give back to the community", any other good reasons why testing betas is worth the effort? How can I counter the arguments given above?
Edit:
As Dirk Eddelbuettel pointed out in the comments, part of the deal is preventing the path variables in Windows. I have some ideas on that, but pointers on how to practically organize your computer for testing R-devel versions are greatly appreciated as well.
I fear you misunderstand. This may not be straightforward or obvious at first so maybe this helps:
"patched" is not "beta". Patched is what R 2.12.1 will be.
There is no conflict. It drops in for 2.12.0.
It is a separate download, and a nightly build available from here.
This is not r-devel but r-patched.
It is our duty as users to test pre-releases as well. So if anything, in an ideal word you would have R-patched installed --- as well as R-devel!
Testing can be as easy as installing another version, keeping it outside your path and then adjusting PATH and R_HOME dynamicaly from a script. Testing means running it on your code and data to prevent you from getting bitten by bugs once the new code is released.
I wouldn't have a clue how to test efficiently. I reckon every test I could come up with has already been run by the development team.
I still find it difficult to figure out when something is a bug, and when (most often) it is my own stupidity kicking in.
The problem is, software is not (or not only) going to be used by developers. It is going to be used by people that may not have programming knowledge at all (I'm speaking generally, this is valid for R as well as for any other software).
If the help or the interface or the general way the software is built do not give you enough informations on how to do something, well, that is maybe not a bug, but it is something that can be improved (and pointed out to the devs).
Also, remember that the developers wrote the software. They know how to use it and often they will be biased in testing it mainly by using it correctly and see if it gives the good result rather than by "trying to break it".
By using it in YOUR way (which may possibly be "uncorrect"), you are effectively running tests that maybe escaped the developers, just because they were not thinking of using it like you did.
Currently we are facing following Problem in our Application:
Around 40 % of the Code that is in the Application is never used. That means the Code would be there, and maybe functional, but the Frontend Feature has been shut off so the Users cannot reach the Functionality anymore or other Methods are replacing the old, now deprecated Methods.
What i am currently doing is removing all the old code while not trying to break anything, manually.
The Question is:
Would you remove the old Code, or hope that it may awake some time ... zombie - like
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Should we keep the Code somewhere, as a reference? ( We are using Version Control, but i find it is pretty hard to find old code in the Revision Jungle ... any tips for that? )
Do you have arguments for convincing the team / management / developers that wrote said code?
Reasons to not deprecate and then delete Code?
TL;DR: Delete unused code or leave it as it is? Discuss!
u
If you are certain that the code is unused, definitely delete it. I assume you have a version control system, so if you ever need it again, you can still find the code back.
Deleting the unused code will make the project easier to maintain, and your team probably will end up saving time in the long run (nobody will re-read the code to try and understand what it was used for, nobody will end up changing said code thinking it may still be used...)
However, if your code contains a public API that is distributed, you will probably want to mark the classes/methods deprecated for some time before effectively deleting the code, so the callers have some time to adapt (or inform you of the issue).
Would you remove the old Code, or hope that it may awake some time ... zombie - like
I'd definitely remove it. I hate having to work out if functions ever get called.
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Yes, definitely worth the effort.
Should we keep the Code somewhere, as a reference?
Um, you are using version control softwarev, aren't you?
Although I am using drupal since the D4 series, I only started developing professionally for it with D6, so - despite I did various site upgrades - I was never faced by the task of having to port my own code to a new version.
I know the Drupal community will come up with lot of technical support about changed API's and architectural changes (see the deadwood module for D5-D6 or even these stubs of D6-D7 how-to's for modules and themes).
However what I am looking for with my question is more in the line of strategy thinking, or in other words, I am looking for inputs and advice on how to plan / implement / review the process of porting my own code, in the light of what colleague developers learned by previous experience. Some example:
Would you advice to begin to port my modules as soon as I have time for doing it, and to maintain a concurrent D7 for some time (so I am "prepared" for the D-day) or would you advice to rather wait for the day in which the port will be actually imminent and then upgrade the modules to D7 and drop the D6 version?
Only some of my modules have full test coverage. Would you advice to complete test coverage for the D6 version so to have all tests working to check the D7 port, or would you advice to write my test directing at porting time, to test the D7 version?
Did you find that being an early adopter gives you an edge in terms of new features and better API's or did you rather find that is more convenient to delay the conversion so as to leverage the larger amount of readily available contrib modules?
Did you set for yourself quality standards / evaluation criteria or did you just set the bar to "if it works, I'm happy"? Why? If you set certain standards or goals, what did they where / what will they be? How did they help you?
Are there common pitfalls that you experienced in the past and that you think are applicable to the D6-D7 porting process?
Is porting a good moment to do some refactoring or it is just going to make everything more complex to be put back together?
...
These questions are not an exhaustive list, but I hope they give an idea of what kind of information I am looking for. I would rather say: whatever you think is relevant and I did not list above gets a "plus"! :)
If I did not manage to express myself clearly enough, please post a comment with the info you think I should add in the question. Thank you in advance for your time!
PS: Yes I know... D7 is not yet out and it will take months before important contrib modules will be upgraded... but it's never too early to start thinking! :)
Good questions, so let's see:
(when to start porting)
This certainly depends on the complexity of the modules to port. If there are really complex/large ones, it might be useful to start early in order to find tricky spots while not being under pressure. For smaller/standard ones, I'd try to find a bigger time slot later on where I can port many of them in a row in order to get the routine stuff memorized quickly (and benefit from the probably improved documentation).
(test coverage)
Normally I'd say that having a good test coverage before starting refactoring/porting would certainly be advisable. But given that Drupal-7 introduces a major change concerning the testing framework by moving it to core, I'd expect the need to rewrite a significant amount of tests anyway. So if there is no need to maintain the Drupal-6 versions after the migration, I'd save the time/trouble and aim for increased coverage after the porting.
(early adopter vs. wait and see)
Using Drupal since the 4.7 version, we have always waited for at least the first official release of a new major version before even thinking about porting. With Drupal 6, we waited for the views module before porting our first site, and we still have some smaller projects on Drupal-5, as they are working just fine and it would be hard to justify the extra bill for our clients as long as there are still maintenance/security fixes for it. There is just so much time in a day and there is always this backlog of bugs to fix, features to add, etc., so no use playing with unfinished technology while there are more imminent things to do that would immediately benefit our clients. Now this would certainly be different if we'd have to maintain one or more 'official' contributed modules, as offering an early port would be a good thing.
I'm a bit in a bind here - being an early adopter certainly benefits the community, as someone has to find that bugs before they can get fixed, but on the other hand, it makes little business sense to fight hour after hour with bugs others might have found/fixed if you'd just waited a bit longer. As long as I have to do this for a living, I need to watch my resources, trying to strike an acceptable balance between serving the community and benefiting from it :-/
(quality standards)
"If it works, I'm happy" just doesn't cut it, as I don't want to be happy momentarily only, but tomorrow as well. So one of my quality standards is that I need to be (somewhat) certain that I 'grokked' new concepts well enough in order to not just makes things work, but make them work like they should. Now this is hard to define more precisely, as it is obviously impossible to know if one 'got it' before 'getting it', so it boils down to a gut feeling/distinction of 'yeah, it kinda works' vs. 'yup, that looks right', and one has to accept that he will quite regularly be wrong about this.
That said, one particular point I'm looking out for is 'intervene as early as possible'. As a beginner, I often tweaked stuff 'after the fact' during the theming stage, while it would have been much easier to apply the 'fix' earlier in the processing chain by means of one hook or the other. So right now, whenever I'm about to 'adjust' something in the theme layer, I deliberately take a small time out to check if this can not be done more cleanly/compatible within a hook earlier on. As I expect Drupal-7 to add even more hooking options, this is something I will pay extra attention to, as it usually reduces conflicts and sudden 'breaking of stuff' when adding new modules.
(common pitfalls)
Well - mainly porting to early, finding out afterwards/in between that one or more needed modules were not available for the new version at all, or only in dev/alpha/early beta state. So I'd make sure to compile a complete list of used/needed modules first, listing their porting state, along with a quick inspection of their issue queues.
Besides that, I have so far always been very pleased with the new versions and their improvements, and I'm looking forward for Drupal-7 again.
(refactoring while porting)
One could say that porting is a rather large refactoring in itself, so there is no need to add to the complexity by restructuring non porting related stuff. On the other hand, if you already have to shred your modules to pieces anyway, why not use the opportunity to make it a major overhaul? I'd try to draw a line based on complexity - for big/complex modules, I'd do the port as straight as possible, and refactor more later on, if need be. For smaller modules, it shouldn't really matter, as the likelihood of introducing subtle bugs should be rather small.
(other stuff)
... need to think about it ...
Ok, other stuff:
Resource needs - given some of the Drupal-7 threads, it looks like they are likely to go up, so this should be evaluated before porting smaller sites that sit on a shared/restricted hosting account.
Latest versions first - This one is rather obvious and always stressed in the upgrade guides, but nevertheless worth mentioning: Upgrade core and all modules to their latest current version first before doing a major upgrade, as the upgrade code is highly likely to depend on the latest table/data structures to work correctly. Given Drupals 'piecemeal', one step at a time update strategy, it would be very hard to implement upgrade code that would detect different pre-upgrade states and acted accordingly.