Should we add registerSubclass?

[fischerscode]

This issue is part of #194

Should we add registerSubclass to match the Android/IOS SDK?

Pros:

• usage of custom ParseObject classes would be much simpler

Cons:

• huge change
• existing code might break by updating the SDK

[phillwiggins]

Can you explain the pros in a bit more depth?

[fischerscode]

Often the user can provide a copy-object. This is used to create new objects based on a custom ParseObject class.
By holding this copy-objects in the background, we would be able to create every object based on the right sub class.
As far as I know, included objects in a query are always of type ParseObject. This would be avoidable, too.

In summary: the user would not have to care about providing such copy-objects.

[phillwiggins]

Apologies for the late reply. I still don't actually understand this. Do you have you any examples where this is done already? I understand the Parse Android SDK does but as far as I'm aware there's not too much benefit when using Flutter as we don't have reflection to iterate through class structures?

[fischerscode]

I did was not working on this for a while, too.
But I've started implementing this feature now.
To get an idea what I am talking about, you can checkout my branch.
If you run something like this after the Parse().initialize();

ParseCoreData.instance
      ..registerSubClass("Test", () => Test1())
      ..registerSubClass("Test2", () => Test2())
      ..registerSubClass("Test3", () => Test3());

The SDK will use your custom classes for objects with the classnames 'Test', 'Test2' and 'Test3'.

This should allow you to do something like this:
Test2 test = object.get<Test2>('test');
Without this changes an error gets thrown: type 'ParseObject' is not a subtype of type 'Test2'

[fischerscode]

...adding a Constructor to QueryBuilder where the object the registered sub-classes get uses automatically would be useful, too.

[phillwiggins]

I really like this idea. Seems very logical. Did you have any luck implementing it?

…

On Wed, 15 Apr 2020, 11:37 Maximilian Fischer, ***@***.***> wrote: ...adding a Constructor to QueryBuilder where the object the registered sub-classes get uses automatically would be useful, too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXX2YNNIR5TISO7ATBTRMWE6VANCNFSM4MC6GN7A> .

[fischerscode]

Well, I think something as simple as this should work.

[fischerscode]

@phillwiggins
I've added some more changes to my branch.
I think while working with registerSubclass, there will appear unexpected behavior (the subclass is not used), as I am sure, I have not found every critical initialization of a ParseObject jet.

Should I keep this changes in my fork for now and create a PR once I have managed to build an app using registerSubclass OR should I create a PR to 1.27 now/soon?
I'm fine with both options.

[phillwiggins]

I would keep changes in your fork for now. This would ensure it is fully functional and tested when you do come to create an MR.

…

On Wed, 15 Apr 2020, 15:24 Maximilian Fischer, ***@***.***> wrote: @phillwiggins <https://github.com/phillwiggins> I've added some more changes to my branch <https://github.com/maaeps/Parse-SDK-Flutter/tree/registerSubclass>. I think while working with registerSubclass, there will appear unexpected behavior (the subclass is not used), as I am sure, I have not found every critical initialization of a ParseObject jet. Should I keep this changes in my fork for now and create a PR once I have managed to build an app using registerSubclass OR should I create a PR to 1.27 now/soon? I'm fine with both options. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXUBUXWSP67WYXYGK7TRMW7TFANCNFSM4MC6GN7A> .

[fischerscode]

This feature got merged with #368 .