Skip to content
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

Put name in Pointer __init__ #6

Closed
PJUllrich opened this issue Aug 5, 2017 · 3 comments
Closed

Put name in Pointer __init__ #6

PJUllrich opened this issue Aug 5, 2017 · 3 comments

Comments

@PJUllrich
Copy link
Contributor

As of now, the init function of the object_.Pointer class does not have a field for the name of e.g. a counterparty_alias, however such a name is important when making payments to IBAN numbers. One can set the name afterwards, but this is awkward especially when a Pointer is created in a request map as e.g. shown in the PaymentExample.

I suggest the following changes:
As it is now:

class Pointer(model.BunqModel):
    def __init__(self, type_, value):
        self.type_ = type_
        self.value = value
        self.name = None

My suggestion:

class Pointer(model.BunqModel):
    def __init__(self, type_, value, name=None):
        self.type_ = type_
        self.value = value
        self.name = name
@OGKevin
Copy link
Contributor

OGKevin commented Aug 5, 2017

Hey @PJUllrich,

Thanks for the suggestion 🙏.

The reason its setup this way is because we wanted to stay consistent with the other SDK's. Not all the languages support optional arguments in constructor/initialisation. However we will take this in consideration as of it might be a good idea to change some stuff based on the language. 👍

@PJUllrich
Copy link
Contributor Author

Simply drop the inferior languages and convert fully to the one true language ;-)

@dnl-blkv
Copy link
Contributor

dnl-blkv commented Aug 5, 2017

@PJUllrich yeah I thought of dropping the inferior languages and thus keeping it to C# only... However, there is a definite interest in some of them like Python or PHP.

Just kidding, we want to support all the languages which are in demand among our users. Everyone should be able to work from the system.

The idea seems OK, but here we would stick to this rule:
Compulsory -> to constructor
Optional -> to setter

It is also more visual when you create the objects: you only see in constructor what you MUST put there and nothing else.

But thanks for suggestion! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants