This question is specifically about MooseX::Traits. The method apply_traits has been deprecated and it gives a warning message as follows:
apply_traits is deprecated due to being fundamentally broken.
disable this warning with "no warnings 'MooseX::Traits'"
Can anyone explain why it is 'fundamentally broken'?
It passes its own tests on that method, and it works for what I'm trying to do. Is it because it uses Moose::Meta::Role::apply()?
I cannot tell you what you want to know, but I would advise you to find another way of doing
what you want to do, just to save you a lot of work further down the road.
I attempted to use it in production, and it kept causing problems with other parts of Moose until I ripped it out again. I have forgotten specifics, but ended up talking to one of the main guys behind Moose at that time, and he was unable to help.
Apparently, the situation has not improved. I would heed the warning.
Just a bit of advice, sorry I could not answer your question.
Related
When I run composer updates I'll occasionally get messages that packages are abandoned and I should use a different one instead, like Package webflo/drupal-core-require-dev is abandoned, you should avoid using it. Use drupal/core-dev instead. I don't have experience with Composer so I'm curious as to what is seen as the best practice for replacing outdated packages.
Where do these messages come from? I'm unsure if the source is always reliable.
I think the best practice is quite clear from the message "you should avoid using it". How/When to do this is not as clear. Abandoned packages will not receive updates, but composer will not be able to tell you how difficult it will be to transition to the recommended alternative. It might be that all you have to do is replace the package, because it was only a name change or having to modify your code as well.
In your case webflo/drupal-core-require-dev only contains a composer.json and the required packages match with what the alternative drupal/core-dev provides. That means replacing the package should be as easy as changing the name in your composer.json and then do a composer update drupal/core-dev.
For packages where the answer is not as straightforward, you have to rely on automated/manual tests to see if everything still works. Static code analysis tools might help as well. You will have to set them up before you do the change, so that you can see how their output differs and fix the new issues that come up.
You should do the switch to the new dependency as early as possible. Leaving it in will likely cause more work in the future when replacing it and might pose a security risk (if it is outdated and insecure). I understand that this is not always possible and using something like roave/security-advisories to tell you when there are known security issues in a package might help postponing it and giving some sense of security.
While I'm making an Android app, Eclipse will strike out some things. More specifically, Gallery. Here is a screen shot:
When I hover my mouse over the warnings, it says The type Gallery is deprecated. I don't know what Deprecated means, but I do know that it's a Java term. Any help would be appreciated. Thanks!
(From the question before editing: The term is deprecated, not depreciated. It's a common typo, but worth being aware of for searching purposes :)
It's basically a bit like "obsolete" - you're encouraged not to use classes or methods which are deprecated. Typically the documentation will explain why you're not meant to use them, and give you a better alternative. The deprecated version is only present for backward compatibility, usually.
It's worth taking this seriously - a lot of the time if you're using a deprecated API, you're coming at something from a fundamentally flawed approach. Date is the clearest example of this, where the Java 1.0 API was almost entirely deprecated in 1.1, when Calendar was introduced. Using the deprecated methods in Date is a sure way of storing up problems for yourself.
See the Oracle "How and when to deprecate APIs" page for more information.
Deprecated means it used to support older SDK, but not anymore. Thats why you get the warning.
It is just a warning most of the times it works, but you most be careful because it could cause problem with newer versions.
Deprecated isn't a Java term. It is used in many other things but a lot in programming. It simply means that it is no longer supported...normally replaced with something else. The Android Docs will help you adapt it to what you need depending on what you're doing
Sorry for such broad question, but after some attempts I'm not sure how to use python bindings. I tried to just import "request.py" or "capi.py" but all I got were errors. After adding missing libraries to my search path, I ended with missing symbol "_dispatch queue_attr_concurrent" (which suggest wrong library version?).
My question isn't about that particular error, but rather correct way of interacting with python bindings (and SourceKit itself). I have tried to use precompiled version, and compile it myself (https://stackoverflow.com/a/40033117/1117854), but result was all the same.
Is there something obvious that I'm missing? Or maybe someone with similar experience succeed and have some tips? It's not well documented and I'll probably find solution sooner or later, but I believe I'm not the only one who felt lost after first contact with SourceKit.
I was following this tutorial
http://blog.lukasjoswiak.com/gameplaykit-for-beginners-part-1/
and when I got to the end, I wanted to try to make the towers not completely impassable, but just have a higher cost.
so, I subclassed GKGridGraphNode and added a cost variable, overrode the costToNode function and tried to insert my cost variable into the equation.
I cannot seem to get it to work. The documentation on this is really doesn't explain having node cost beyond mentioning it in the subclassing notes. I was wondering if anyone has managed to do this?
I am probably going about it wrong, but even reading the Swift headers doesn't really give me any clues.
Thanks for the help
Update: Closed as duplicate
I had a similar question, and I used one of my Apple developer support tickets to try to get an answer.
Apple responded and told me it was a known issue, and that there was a potential fix in the iOS SDK 9.2 beta 2, released November 3, 2015. I verified that the tests in my test project pass in 9.2b2, and so I expect that version to resolve this issue.
I have been using Frontier::RPC2 for my XML-RPC server, with Frontier::Client on the client side... but have noticed these modules have not been maintained recently.
Discussion at the bottom of this page mentions some fresher alternatives on CPAN. What would the pros and cons of these be? I honesty don't have an immediate need to switch, but there are some annoying "uninitialized" variable warnings produced by Frontier::RPC2 which I'd love to rid myself of... they are clogging up and making it difficult to find more salient warnings in my webserver log.
Any recommendations for upgrading my web service?
You could just fix Frontier::RPC2 so it's warnings clean. That's kinda the point of free and open source software. :)
If you are already using this module and it works fine except for the warnings, why switch? Just fix the warnings. Submit a patch to RT for the module. If the maintainer has disappeared, the admins at modules#perl.org can help you get your patch applied.