Does the KeyValuePairs struct have a similar property to what 'default' does in an enum, i.e. a catch-all value in case a given key is not found? Or is there a way to recreate the same effect without built in functionality?
I need this to work with some data I'm fetching from an API (and I think I have to rely on KeyValuePairs as this is what Swift's new charts library uses for custom colouring of charts).
Related
I have a list of objects that need to be loaded into my app. But the load order matters. I’ve created a var which is a part of each object that indicates the load order where the lowest number gets loaded in first. Then I’ve set the default to be 9999. I can manually set this value on each object and override the default. Currently this is where I’m at.
Should I add more objects which need to be loaded in a specific order in the future, I want to make sure there are no conflicts. It seems to me like I could do that by making each load order number on the objects unique, (i.e. no duplicate numbers in all the load order variables).
Is there a way I can make Xcode throw an error or warning if it detects that anything conforming to a protocol has the same value on a variable from that protocol as any of the other conforming objects?
Well, you could list all the objects in an array literal in the order you want them loaded, and forgo the load order property entirely:
let objectsToLoad = [
ObjectDescriptor("hello"),
ObjectDescriptor("world"),
]
But if you have objects defined in disparate places and don't want a single unified array literal that lists them all, then I don't think you can get help from the compiler (or the linker).
In a few months, when Swift will have macros, you'll probably be able to get help from the compiler or the linker. The strategy is to use a macro to wrap each load-order constant in a macro that also generates some type definition whose name includes the constant, e.g. enum _LoadOrder_1 {}, enum _LoadOrder_357 {}, etc. Then, if you have a duplicate, either the compiler or the linker will fail due to the multiple definitions for a single identifier.
I wanted to know if there is a way a disable a particular operation on a PKCS#11 Object. For instance, I create an Object (AES Key) using C_CreateObject. I would want to set some property in this object that pauses/ disables the use of this object for any encryption/ decryption use. Is this possible ? Can we set the CKA_DECRYPT value to CK_FALSE to disable Decrypt operations? Also can this be changed multiple times using C_SetAttributeValue
Theoretically PKCS#11 standard don't restrict your from changing values of properties.
Practically your possibility to change the values after object created dependent on your PKCS#11 provider.
My suggestion that this property is immutable.
Try to set this values during creation of key or change values during copying of key object using C_CopyObject.
Another solution is to implement your own PKCS#11 proxy library with custom logic inside of PKCS#11 exported functions.
I'm attempting to parse json from the GitHub API with play-json, and encountering a problem with the merge_commit_sha field on Pull Requests (incidentally, I know this field is deprecated, but don't want to discuss that in this parsing problem!). Unfortunately merge_commit_sha field comes back as the empty string in some cases:
"merge_commit_sha": ""
This is how the field is declared in my case class:
merge_commit_sha: Option[ObjectId],
I have an implicit Format[ObjectId], which does not tolerate the empty string, because that's not a valid value for a Git hash id. I'm also using a play-json macro-generated Read[PullRequest], which I'd like to keep on using, in preference to individually declaring reads for every single field on pull requests.
As I've declared the field to be an Option, I'd like "merge_commit_sha": "" to be read as the value None, but this is not what currently happens - a string is present, so the Format[ObjectId] is invoked, and returns a JsFailure.
One thing I tried was declaring an implicit Format[Option[ObjectId]] with the required behaviour, but it didn't seem to get used by the macro-generated Read[PullRequest].
You can define a custom Reads and Writes yourself.
Using Json.format[MyType] uses a Scala macro. You may be able to hook into that. Although, 'extending' a macro for this one case class just seems wrong.
Custom Reads and Writes might be a little 'boilerplate-like' and boring, but they have their upsides.
For example if your json has a bunch of new fields on it, you wont get a JsError when validating or transforming it to a case class. You only take what you need from the JSON and create objects. It also allows for a separation between your internal model and what you're consuming, which in some cases is preferred.
I hope this helps,
Rhys
EDIT
After using some other JSON libs I may have found what you are looking for.
I know the question was asking specifically after Play JSON.
If you're able to move away from Play JSON, Look at spray-json-shapeless specifically JsNullBehaviour and JsNullNotNone REF.
Let's say I have a struct definition like this:
struct SomeStruct {
1: optional binary content;
2: optional binary newConetent;
}
What is the best practice to deprecate the first field ("content"), without affecting deployment? The deployment of the new code will be into multiple applications that is using this thrift structure? (Assuming some applications are still using the "content" field before the deployment)?
Thank you!
The recommended solution is to comment out the field but leave it in the IDL. This prevents the field ID from becoming reused later for sth. else which then of course would produce incompatibilities.
If "in use by clients" means that they are accessing the outdated field for RPC only, that's not a problem w/regard to Thrift. Thrift will behave just like with a new field.
If however you mean that the field is used for serialization and the old data contain relevant information that needs to be converted somehow into the new format, you will have to leave the field active in the IDL. You may consider renaming the field in order to make it visible to the target audience of your IDL.
I'm using the MvvmCross Json Localisation plugin. Everything works well for View Model specific resource files using a TextSource property on the View Models.
I've added SharedTextSource and ErrorTextSource properties on the View Models however I can't find an example of how to use the Android MvxLang binding shortcut with these. I think it's something like:
local:MvxLang="Text Buy, Path=SharedTextSource"
However I get told "You cannot specify ConverterParameter more than once". Do I have to use the longhand binding for shared and error text sources?
Incidendally, MvvmCross is one of the best frameworks I've ever used.
The parser for Lang bindings is in https://github.com/slodge/MvvmCross/blob/v3/Cirrious/Cirrious.MvvmCross.Binding/Parse/Binding/Lang/MvxLanguageBindingParser.cs
It parses 4 things for each Lang binding:
Key - the text lookup - used as parameter to the Converter
Source - defaults to "TextSource" - essentially this is used as the binding Path
Converter - the value converter used (defaults to "Language")
FallbackValue - the value to use for missing Source - useful for design time data
So for your binding, you can use
lang:MvxLang="Text Buy, Source=SharedTextSource"