🐛 Not a Bug Report: There are two different Account classes

[vrescobar]

👟 Reproduction steps

There are two accounts: models.Account and appwrite.Account

👍 Expected behavior

While this is not an actual bug, it is annoying to say the least, and usually a bad practice. I would like to propose to refactor appwrite.Account (services/Account.dart) to AccountService and avoid name clash in the files that both definitions are needed.

👎 Actual Behavior

Unambiguous naming is hard, and I ended up with quite long refactoring due autoimports and large misunderstanding.

🎲 Appwrite version

Version 1.0.x

💻 Operating system

MacOS

🧱 Your Environment

Flutter

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[vrescobar]

Perhaps it is between bug (usability) and enhancement.

[lohanidamodar]

@vrescobar this is the downside of language that doesn't support namespace. We don't want to switch to AccountService for the sake of consistency across our SDKs and platforms. And we don't yet have a better solution than this where you can import import package:appwrite/models.dart as models to avoid name clash. Let us know if you have other better suggestions, which can help us be consistent and provide better usability as well.

[vrescobar]

I can totally understand your point, and yes, I also import it as models. However still a week after, having a class instance that returns an object of a class with the same name lead me to many subtle messes during this last week, even being aware of it. Another option could be renaming the user account to User or Profile, perhaps that could also make sense in the other frameworks as it is often recommended in semantic maps to have different names for different concepts. Sure that you may want to just close here now this not-a-bug report as many more options aren’t there, but here lays my feedback. Atentamente/ Kind regards/ mit freundlichen Grüßen Víctor R. Escobar vrescobar.com

…

On 21. Sep 2022, at 04:38, Damodar Lohani ***@***.***> wrote:  @vrescobar this is the downside of language that doesn't support namespace. We don't want to switch to AccountService for the sake of consistency across our SDKs and platforms. And we don't yet have a better solution than this where you can import import package:appwrite/models.dart as models to avoid name clash. Let us know if you have other better suggestions, which can help us be consistent and provide better usability as well. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[biovolt]

or the sake of consistency across our SDKs and platform

I feel consistency must come second if it causes way worse side effects like code that does not compile and needs extra code in many places.
This causes way more other inconsistencies in the code.

[M123-dev]

I totally agree with this, code generation and consistency is great, but this inconvenience is really not very pleasant

[jasimameen]

we can access the Service class by defining a custom Type for the Account.

// access Account using AccountService Type
typedef AccountService = Account

class Account extends Service {
// . . .
}

Using the above approach would solve this issue and also it won't affect existing written programs that use this class.

i want to contribute.

[stnguyen90]

The SDK now uses User instead of Account:

sdk-for-flutter/lib/src/models/user.dart

Line 4 in 54f30fa

class User implements Model {