> Yet I am new to Nim (coming from C, C++, Python) and wonder, what this.x then > will mean in my Euler class. Is it the pointer to the method x or is it the > attribute x?
I tried Skaruts's code in the [Nim playground](https://play.nim-lang.org/#ix=27xV) and it seems accessing `Euler(x: 3.0).x` doesn't call the method, but returns the field value. Maybe the compiler should at least print a warning here? On the other hand, I guess if you use `eulerInstance.x` from _another_ module, it will be a call to the method because the _field_ `x` is private. I find this confusing, so for clarity I'd rather name the field `privateX`, which probably is a somewhat cumbersome name. I'd be interested in what conventions other people would use here! If you write `eulerInstance.x()` there's no ambiguity though (see [https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax](https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax) ). Conversely, you can pass a proc without calling it to a higher-order function like `map`. _Personally_ I almost always use brackets to make clear that I mean the call. Exceptions are `echo` and cases where I understand a Nim API as a DSL (domain-specific language), like for `suite` and `test` from the `unittest` module. > I consider this insensitivity being a severe restriction, the lang designers > are pulling the users' leg here. As someone who has programmed mainly with Python for 20 years, so far I don't have a problem with the case insensitivity. _Why_ do you think it's a "severe restriction"? Note that the first letter of an identifier is case-sensitive to allow distinction between a type (with initial uppercase letter by convention) and instances (with initial lowercase letter by convention).
