I advised against having the same name to avoid having to deal with the dot
operator call order.
Maybe the issues I had were out of misuse or confusion. Or maybe I was using
templates and that can cause issues? I can't remember...
But then, I would love if @mratsim could elaborate on why he advised against
doing that.
I'm interested in the following use case:
type
MyType* = object
x: int
...
proc x*(mt: MyType): int =
# This is also the user API for the type.
# Have some side effect, for example update a cache.
...
mt.x
var mt = MyTy
> If your type has an x property, and you want a x= setter for it, you'll have
> to rename x to something else, to allow proc x=() to exist
You don't have to rename x. As mentioned in the
[manual](https://nim-lang.org/docs/manual.html#procedures-properties) The
resolution order of dot is well d
> How do you solve this problem
First, I can not remember that I myself cared for the fact if a symbol in
source code I was reading or working on was local/private or public. There may
exists cases when one cares, but I just can not remember a concrete case.
Second, we can use unicode for symbo
Sorry to revamp this, but I've been away...
@mratsim
> Python has no control over visibility, all fields in a class are visible by
> default.
>
> **The leading underscore convention is a social workaround to a missing
> technical feature.**
>
> In Nim this is not a problem, and even less so b
Another possibly constructive, possibly not suggestion (that would have
prevented this entire thread from happening, as just one example) is to have
"more room" for convention support. For the root of this thread, we could have
identifier normalization not collapse '_' at the beginning (or end),
Huh? We do have `--styleCheck:error` and I personally ensured the full stdlib
and compiler source code works with it. In fact, for the compiler it's always
enabled so that every contributor has to obey. (Though there seems to be a bug
with it that I need to look into...)
This is simply a judgement call of the compiler authors to name the command
"lowercase gcc" to avoid inflicting caps lock or shift on people, but it's a
judgement call the case-sensitive file system enables rather than blocks.
When I say `whence -m '*[A-Z]*'|wc` in Zsh. I get about 200 commands
> Personally, I like just full sensitivity best.
This is of course a valid opinion to have, but what I'm missing in these
discussions is that Unix's case sensitivity introduced a de facto standard of
alllowercase for every command. In other words, whenever you type `gcc ...` on
the command line
One thing often missed in discussions of insensitivity is the very different
user scenarios of "interactive" vs. "written once to be read many times".
Insensitivity tends to be more popular in the interactive/IDE/REPL setting in
the same way as TAB/whatever auto-completion. My first encounter wi
> Hungarian notation encodes the type in the name and is widely regarded as the
> wrong idea. Why should it be any different with visibility.
While i completely agree, it is my impression that it is really helpful for
beginners to carry around the type information in their first few programs - a
`multiplicative_inverse` and `multiplicatively_inversed` of course! 😉
Python has no control over visibility, all fields in a class are visible by
default.
**The leading underscore convention is a social workaround to a missing
technical feature.**
In Nim this is not a problem, and even less so because it's a static language
so visibility issues are resolved at c
> Rationalizations tend to be disingenuous
They tend to be yes, but encoding visibility in the name is a terrible idea
because ideally names are about the semantics and only about them. Hungarian
notation encodes the type in the name and is widely regarded as the wrong idea.
Why should it be an
I'm not really after the possibility of leading underscores in Nim. That said,
I'd be interested in what conventions you use to distinguish a private name and
the name of a corresponding accessor proc.
So, which conventions do you use or have seen?
Having _ as initial variable name only acts as visual cue, it's not related to
readability or anything.
Having clear/distinct/helpful/noisy visual cues doesn't change the fact whether
the code is well written or not.
What actually helpful is good structure and sane APIs. Whatever the variable
And before Python 3.0, there were probably people who did complain about their
absence. Rationalizations tend to be disingenuous, and there's a lot of that
here. Not that it matters, because Nim's handling--and lack of handling--of
underscores is not something that's going to change.
> People don't complain about Python not allowing unicode characters as
> identifiers (something possible in Julia for example).
For the record, Python 3 _does_ allow unicode characters in identifiers. :-)
$ python3
Python 3.7.5 (default, Oct 17 2019, 12:09:47)
[GCC 9.2.1 2
@Libman
I think an MC Hammer emoji would be more appropriate than your smiling poop
emoji... If only one existed... 🤔
Don't use the same name for the field and the proc. Also don't use `methods`
when you don't need inheritance/dynamic dispatch it's a pessimization. Use
`proc` instead.
Lastly, naming conventions allow consistency within a language and depends on
many factors. People don't complain about Python
Seems to be conflicting with property `x`. But you're also calling `x` as a
method with a parameter, when the method that takes a parameter is `x=`. What
you want there is something more like:
euler.`x=`(42)# I suppose using back-ticks is advisable, as sometimes
this doesn't w
@Skaruts: Alas, Nim doesn't accept this code:
### Define the class
#
type
Euler* = object
x, y, z, a, b, c: float64
method dump( self: Euler): string =
return "x"
method print( self: Euler): void =
echo( self.x, ", ", self.
@sshw
> I tried Skaruts's code in the Nim playground and it seems accessing Euler(x:
> 3.0).x doesn't call the method, but returns the field value.
That's because you're accessing it from within the same module. I didn't think
of mentioning this before, but the trick will only work if you acces
According to the upcoming Official 21st Century Universal Code Style Guide, the
correct way to write this is:
type
Euler* = object
💩x, 💩y, 💩z, 💩a, 💩b. 💩c: float64
method x( this: Euler): float64 =
return this.💩x
Run
Leading and trai
@sschwarzer: You hit the point, thank you!
> How underscores improve readability?
The idea is that you could use `_name` for a private field and `name` for an
accessor proc. It's a nice convention. So I agree, it doesn't improve
readability directly, or maybe just in the sense that you avoid less readable
names like my `privateX` above.
But Nim wont use underscore for private vs public. How underscores improve
readability?.
`let __variable = 42` Vs `let variable = 42`.
> 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).
The comparison with a leading comma is misleading. It's not only about scope
(private vs public) but about readability, when a leading underscore is used.
Paul
A workaround, thank you.
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 consider this insensitivity being a severe restriction, the lang designers
are pulling the users' le
_At least_ in Python, an underscore at the beginning of a variable means it's
private and shouldn't be accessed by client code.
At some point I was wondering the same as the OP, but I think in Nim you just
use the `*` suffix to distinguish "public" and "private" fields:
type
An underscore is a separator so it's like saying "I need to start my
identifiers with a comma". Seems totally unreasonable, doesn't it? ;-)
See
[https://nim-lang.org/docs/manual.html#lexical-analysis-identifiers-amp-keywords](https://nim-lang.org/docs/manual.html#lexical-analysis-identifiers-amp-keywords)
Please note that Nim identifiers cannot start with an underscore, except for
the special identifier `_`.
frogot for 'x=' this: VAR Euler
Nim's compiler is insensitive to underscores, such that _x and x are the exact
same thing, unlike in other languages (it's also case-insensitive, with the
exception of the first letter).
There's ways to do what you're trying to do there, although I'm not the best
person to tell you what's the m
Nim seems to try to force me into a certain naming scheme, wants to define how
I name my vars, what's allowed and what not. Please, tell me, I'm wrong. So,
how can I use a leading underscore with my attributes:
type
Euler* = object
_x, _y, _z, _a, _b. _c: float64
38 matches
Mail list logo
