Is there any operator on Mono that would allow me to log fact that mono was empty?
I cannot use hasElement() because I need result and I don't want to introduce hacky solutions like abusing switchIfEmpty
You could use doOnSuccess and test if data is null
.doOnSuccess(data -> {
if (data == null) {
//onEmpty behavior
}
})
Related
Future<bool?> f() async => true;
void main() async {
final proceed = await f();
if (proceed) {...} // Error
if (proceed != null && proceed) {...} // Works but too verbose
}
Is there any shorthand or a better way of proceeding instead of writing a long proceed != null && proceed check? I know I might be missing something so trivial.
Note: I know a default value can be provided to proceed but that's just not my use case. Bang operator can do the trick iff bool is actually not null.
Sounds like a case where you can use the ?? operator which are documented here in the language tour:
https://dart.dev/guides/language/language-tour#conditional-expressions
It will allow you to rewrite your long if-statement into:
if (proceed ?? false) {...}
?? means here that we want to use the value of proceed as long as it is not null. In case of null we want to use false as the value.
One drawback of this is that it does not seem like Dart makes any type promotion of proceed compared to the following where proceed afterwards is promoted to a non-nullable type:
if (proceed != null && proceed) {...}
Not sure if there are a Dart issue on that.
I am attempting to define a lambda in a FactoryBot like so...
contact_methods = %w[Phone Email Snail\ Mail Carrier\ Pigeon]
factory :my_object do
transient do
remove_used_value = -> (x,y) { x.reject { |a| a == y }.sample }
end
first_contact_option { contact_methods.sample }
second_contact_option { remove_used_value.call(contact_methods,first_contact_option) }
end
However, when I run FactoryBot.create(:my_object) I get the error undefined method remove_used_value for #<FactoryBot::SyntaxRunner:0x00007fb2ac238960>
I define this as a lambda because there are several other fields that need this same functionality in the Bot. The strange thing is that this was working just fine yesterday, except the logic in the lambda wasn't returning the expected result. After reworking the logic and testing the lambda in the CLI I figured out logic that works, but all of the sudden it's not recognizing the lambda is there.
Is there something wrong with my definition? Also, is there a more preferred way of doing something like this either way?
Most probably replacing this assignment
remove_used_value = -> (x,y) { x.reject { |a| a == y }.sample }
with the proper dynamic attribute defined via a block
remove_used_value { -> (x,y) { x.reject { |a| a == y }.sample } }
will fix the issue.
(To be honest, I would avoid such kind of randomization of the object properties that I don't control in full - this often leads to either flaky specs that fail all of a sudden or, even worse, subtle bugs in the app logic that were not caught by the specs; but I understand that it might be a good solution for the particular use case)
In ASP.NET MVC, when we call a post action with some data, we check ModelState and in case some validation error, it would be falst. For a big Enter User Information form, it is annoying to expand each Value and look at the count to see which Key (9 in attached example image) has validation error. Wondering if someone knows an easy way to figure out which element is causing validation error.
In VS2015+, you can use LINQ in the Immediate Window, which means you can just run the following:
ModelState.SelectMany(
x => x.Value.Errors,
(state, error) => $"{state.Key}: {error.ErrorMessage}"
)
I propose to write a method:
namespace System.Web
{
using Mvc;
public static class ModelStateExtensions
{
public static Tuple<string, string> GetFirstError(this ModelStateDictionary modelState)
{
if (modelState.IsValid)
{
return null;
}
foreach (var key in modelState.Keys)
{
if (modelState[key].Errors.Count != 0)
{
return new Tuple<string, string>(key, modelState[key].Errors[0].ErrorMessage);
}
}
return null;
}
}
}
Then during debugging open Immediate Window and enter:
ModelState.GetFirstError()
Sounds like you're looking for debugger enhancements. I recently came across this product in the visual studio gallery.
http://visualstudiogallery.msdn.microsoft.com/16acdc63-c4f1-43a7-866a-67ff7022a0ac
I have no affiliation with them, and haven't used it. It's also a trial version and have no idea how much it costs for the full thing.
If you're more focused on the debugger side of things, have a go with the trial copy of OzCode. It enhances the Visual Studio IDE by replacing the usual debugging tooltip with it's own, more powerful, debugging tooltip. It's hard to epxlain with words, check out their website, they have a gallery of features on there.
I've been playing around with the beta for a few weeks, and it's proved a very valuable tool. You can query against data in the debugger using OzCode. For example, you could query items in the ModelState by filtering against the Values collection.
I am using a third party API that rather clumsily makes use of ref parameters to produce outputs. Personally I really hate this design of an API but it's what I have available to me right now. I've had to hide the datatypes of the API slightly due to proprietary code but this should be irrelevant to the problem at hand.
Anyway in C# I can pass a null reference as a ref parameter successfully as follows:
IDataType tl = null;
bool success = api.myFunction(ref tl);
However in F# the following will not work
let mutable tl : IDataType = null //null reference assignment in F#
let success = api.myFunction(&tl) //& means ref in F#
It returns a null reference exception error. No such error is returned in C#.
Has anyone experiences this before? I am thinking it must be a bug in the API itself which is relatively ancient design.
**Edit: This should be closed, I believe the answer does not lie in the F# code but in the API as it's already a number of known bugs similar to this.
Quick and dirty prototyping of your API in C#
namespace API
{
public interface IDataType { void Hi(); }
public class API: IDataType {
public void Hi() { System.Console.WriteLine("Hi!"); }
public bool MyFunction(ref IDataType iface) {
iface = new API();
return true;
}
}
}
and then using it from F# exactly your way while staying within the same CLR:
let mutable iface : API.IDataType = null
if API.API().MyFunction(&iface) then iface.Hi()
works without any problem.
So, indeed, your problem is specific to your given API and has nothing to do with the form of its use from F#.
Using a ref cell is also an option here. Does this work?
let tl = ref null
let success = api.myFunction(tl)
The problem was with the API being compiled in .NET 2.0 which works fine under C# but not F#.
I have these interfaces:
public interface IBaseInterface
{
function Method():void:
}
public interface IExtendedInterface extends IBaseInterface
{
function MethodTwo():void;
}
...and a vector of type "IBaseInterface" I need to iterate through:
var myVector:Vector.<IBaseInterface> = new Vector.<IBaseInterface>();
I need to perform an operation on objects that use IExtendedInterface. Which is the preferred option?
for each(var obj:IBaseInterface in myVector)
{
// Option 1:
var tmp:IExtendedInterface = obj as IExtendedInterface;
if(tmp != null)
tmp.MethodTwo();
// Option 2:
if(obj is IExtendedInterface)
IExtendedInterface(obj).MethodTwo();
}
I'm sure the info I'm looking for is out there, it's just hard to search for "is" and "as"...Thanks in advance!
I tried a little test to find out which is faster, expecting the "as" variant to be slightly better, because a variable assignment and check for null seem less complex than a type comparison (both options include a type cast) - and was proven right.
The difference is minimal, though: At 100000 iterations each, option 1 was consistently about 3 milliseconds(!) faster.
As weltraumpirat says, Option 1 is faster,
But if you are working on your own code, and no one else is going to ever touch it then go for it.
But if its a team collaboration and you are not going to run the operation 100,000 times with mission critical to the millisecond timings, then Option 2 is much easier for someone looking through your code to read.
Especially important if you are giving your code over to a client for further development.