New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support IMap
and IMapView
#530
Conversation
@override | ||
bool operator ==(Object other) { | ||
if (identical(this, other)) return true; | ||
|
||
return other is GUID && | ||
other.Data1 == Data1 && | ||
other.Data2 == Data2 && | ||
other.Data3 == Data3 && | ||
other.Data4 == Data4; | ||
} | ||
|
||
@override | ||
int get hashCode => | ||
Data1.hashCode ^ Data2.hashCode ^ Data3.hashCode ^ Data4.hashCode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These overrides are required for Map<GUID, XX>
types (e.g. Map<GUID, Object?>
) to work properly.
/// Gets the key of the key-value pair. | ||
K get key { | ||
if (isSameType<K, GUID>()) return _key_GUID as K; | ||
if (isSameType<K, int>()) return _key_Uint32 as K; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used Uint32
for int
keys since it is the only int
type to be supported for IKeyValuePair
: https://github.com/timsneath/win32/blob/339c6e4ac04a9d2f2c1933c958bc0893be65dee2/lib/src/winrt_constants.dart#L147-L148
V get _value_enum { | ||
final retValuePtr = calloc<Int32>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used Int32
here for enum values since all supported enum types for IKeyValuePair
are Int32
type (e.g. AppCapabilityAccessStatus
, ChatMessageStatus
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an astonishing piece of work. You have outclassed me! I've been busy in my free time fixing up another package that I own which has bitrotted a little, so I'm thrilled to see you continuing to make progress here. A few comments inline to check out.
At some point, we need to converge on a release, since there are folk waiting on more mundane fixes (e.g. some of the Win32 APIs that have been added over the last couple of months. I'm thinking of shipping a 3.0.0-pre
based on what we've got so far to help out those who are waiting, and then we can keep iterating until you feel the new WinRT projection has settled down. WDYT?
} | ||
} | ||
|
||
PedometerStepKind get _key_PedometerStepKind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgive me, but this seems weird here. Why would such a specific type as PedometerStepKind
be embedded in a generic collection object like this? There could be hundreds of these, couldn't there? What if we decide (as is likely) to partition Windows.Device.Sensors
into a different export from Windows.Foundation.Collections
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are the supported key-value pairs of IKeyValuePair
according to IIDs taken from here:
https://github.com/timsneath/win32/blob/339c6e4ac04a9d2f2c1933c958bc0893be65dee2/lib/src/winrt_constants.dart#L62-L148
According to these, there is only one enum type (PedometerStepKind
) used as a key type of IKeyValuePair
. It seemed easier to handle it this way instead of adding a new parameter (keyCreator
) that takes an enum constructor for the key type of ÌKeyValuePair
which will allow me to create an instance of that enum type.
I can modify the implementation to handle these types with the keyCreator
parameter I mentioned above if that's what you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the best thing is to make the PedometerStepKind
pieces an extension method in winrt/device/sensors? I don't know that this is the right answer, but it does feel like a very odd outlier. Are there other classes that might have a similar pattern, I wonder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the best thing is to make the
PedometerStepKind
pieces an extension method in winrt/device/sensors?
I've created extension methods for the PedometerStepKind
pieces but I'm not sure if it's the way you wanted it. Could you take a look?
Are there other classes that might have a similar pattern, I wonder?
I don't think there are.
@@ -38,6 +33,93 @@ class IPropertyValue extends IInspectable { | |||
factory IPropertyValue.from(IInspectable interface) => | |||
IPropertyValue.fromRawPointer(interface.toInterface(IID_IPropertyValue)); | |||
|
|||
Object? get value { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this should be implemented by keeping the interface autogenerated but adding an extension method for this helper method? The more that is autogenerated, the better, obviously -- both less prone to errors and more likely to catch errors in the generation. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes sense. Before doing that, I need to modify the generator to fix the deallocation bug I mentioned below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@@ -363,24 +445,18 @@ class IPropertyValue extends IInspectable { | |||
GUID getGuid() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this deallocation a bug in the generator code? Or is this fix unique to this interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this deallocation a bug in the generator code?
Yeah, it is a bug in the generator. retValuePtr
should not be freed for structs (just like for COMObject
s).
I don't know how can we avoid memory leaks from these as NativeFinalizer
cannot be used with structs.
Thank you!
That's a great idea. I saw your comment and I think these are great. I'll let you know if I come up with something to add there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Closes #486
IKeyValuePair
,IMap
, andIMapView
interfacesPedometerStepKind
enum (used as a key type for the above interfaces)PropertySet
,MediaPropertySet
,StringMap
andValueSet
classes (implementations of theIMap
)NotificationData
classAfter we land this, I'll send a PR that will include support for Windows.Data.Json and tests for
IMap<String, IJsonValue?>
.As for the
IMap<Object, Object?>
type, I haven't been able to test it as the ResourceDictionary is the only API that supports it, and I think it only works inUWP
apps.