Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!

Yorick Maloy

+ Follow
since Oct 22, 2019
Yorick likes ...
Eclipse IDE Java Windows
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Yorick Maloy

Campbell Ritchie wrote: Don't do arithmetic with Math#random(). For everything except a double x such that 0.0 ≤ x < 1.0, use a Random object. By the way, your arithmetic won't compile because its result is a double not an int.

Thanks for pointing that out!

You got used to randrange()

that was more of a lucky copy-paste
But what I don't like about declaring variables in a constructor is that passed variables are potentially changed during the construction (example will be below). There also can be certain operations between assignments. Which would mean that I should just declare variables to default values and only then set them.

Anyway, what do you think of the following implementation? Does it make any sense? Or would it better to avoid it?

Also, if I understood correctly, method overloading doesn't exist either. That's sad
11 months ago
I'm quite new to Python and I was wondering - how to improve readability of fields in classes?

For example, let's take the following class

You may notice it has field "field" and then "self.field". First one is a static field. Second one is instance field. So, Java representation of it would be (even though it doesn't work):

In Python it creates some confusion mainly because fields can share the same name, and static field can be accessed using "self" (in Java we can access static fields using "this" as well, but at least IDE complains).

So, if the field is not used statically, then there is no point of declaring it as such in a first place. Which means that all instance fields have to be declared inside of __init__() which decreases readability (for me, I'm used to have all fields clearly visible and in one place).
SO, how can I declare fields such that they are easy to read, but don't create confusion as static fields do?
11 months ago
I think it really depends on a background of anyone answering. I see 2 possible answers: 1 and 16. When working with fractions on paper I often write something like [8/2   *   (2+2)], meaning [ (8/2)*(2+2) ], which would be 16. At the same time, I sometimes write [8/   2 (2+2)] avoiding brackets around [2*(2+2)] which results in [8/(2*(2+2))], which is 1.

And that's the story of why I prefer to put more brackets than needed when coding
11 months ago