Nice discussion.
Thanks Christian.
On Mon, Feb 12, 2018 at 10:36 AM, Christian Haider
wrote:
> Hi,
>
>
>
> sorry to jump in here, but I think that this pattern is bad.
>
>
>
> For your approach, you need to have setters on the configuration.
>
> Do you really want to have methods to set the usern
Nice design henrik. You made me think so this is good.
On Sun, Feb 11, 2018 at 11:27 PM, Henrik-Nergaard wrote:
> Hi Peter,
>
> I would just fill in the configuration and have it give me the correct
> client which uses the configuration instance.
>
> =
> | client |
>
> cli
Sean P. DeNigris wrote:
>
> Are you talking about the solution described in this mailing list thread
Yes, that's the one. I would welcome a (blog)post about this
Stephan
Stephan Eggermont-3 wrote
> See the recent post about using volatile memory to avoid passwords and
> sessions being stored in the image
Are you talking about the solution described in this mailing list thread
[1]:
>For my use case, since this api key is only sent to an ffi callout,
>my solution
Christian Haider
wrote:
> sorry to jump in here, but I think that this pattern is bad
The example with user and password is very atypical, as it has different
security requirements from most other code. See the recent post about using
volatile memory to avoid passwords and sessions being stored i
Hi,
sorry to jump in here, but I think that this pattern is bad.
For your approach, you need to have setters on the configuration.
Do you really want to have methods to set the username and password from the
outside – maybe even after you logged in?
To me an object like your configura
Hi Peter,
I would just fill in the configuration and have it give me the correct
client which uses the configuration instance.
=
| client |
client := TwitterConfiguration new
username: 'stuff';
password: 'password1';
port: '1234';
useHttps;
client.
TwitterCo
> Am 11.02.2018 um 21:34 schrieb Stephane Ducasse :
>
> Arghh no magic please.
> I got burned by too much DNU override.
+ magic number
Norbert
>
>
> On Sun, Feb 11, 2018 at 8:17 PM, Christian Caldeiro
> wrote:
>> Maybe using directly TwitterClient, but using #doesNotUnderstand: to
>> de
Arghh no magic please.
I got burned by too much DNU override.
On Sun, Feb 11, 2018 at 8:17 PM, Christian Caldeiro
wrote:
> Maybe using directly TwitterClient, but using #doesNotUnderstand: to
> delegate there message sends to the configuration object(kind of a proxy
> pattern). That way the
Maybe using directly TwitterClient, but using #doesNotUnderstand: to
delegate there message sends to the configuration object(kind of a proxy
pattern). That way the TwitterClient class doesn't became so heavy.
Christian
On Sun, Feb 11, 2018 at 1:35 PM, Sven Van Caekenberghe wrote:
> Why not d
Why not directly on TwitterClient ? That would be easiest for the user, then
they do not need to know about TwitterConfiguration. Anyway, that is how I do
it most often. The disadvantage is that TwitterClient might become a bit heavy,
API wise, but you can delegate internally.
> On 11 Feb 2018,
11 matches
Mail list logo
