think twice about using setters. They should be not used for
> initialization / configuration!
>
>
>
> My 2 cents.
>
> Cheers,
>
> Christian
>
>
>
>
>
>
>
> Von: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] Im Auftrag von
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
tian
Von: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] Im Auftrag von
Peter Uhnák
Gesendet: Sonntag, 11. Februar 2018 16:26
An: Any question about pharo is welcome
Betreff: [Pharo-users] Object configuration idioms
Hi,
are there any best practices/idioms in
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,
Hi,
are there any best practices/idioms in regards to object
configuration/building?
Let's say I want to configure a TwitterClient that requires a username and
a password that is stored in a separate object TwitterConfiguration
a) the basic approach (either separate sends or via cascade, that is
12 matches
Mail list logo
