Issue #15991 has been updated by aquaj (J=E9r=E9mie Bonal).


shevegen (Robert A. Heiler) wrote:
> I do not see why this would make the design more "coherent", per se.

I guess "design coherence" is a very subjective notion \^\^" =

What I meant by that is that in most cases in Ruby, whether an identifier i=
s a local variable or a method call is transparent.
I've also often heard (especially when talking about why methods are a bit =
clunky to pass around in Ruby) that it was a conscious design choice that d=
id matter to matz.
Because of that it feels "natural" (coherent? ;-)) to me that the naming ru=
les should be more uniform between local variables and methods.

shevegen (Robert A. Heiler) wrote:
> I do not see why adding "?" to variable names as such would require of on=
e to also add "!"
> as well. I often don't fully understand why this is said, either. "?" and=
 "!" do not have
> the same, and not even opposing use cases either. Their use cases and rat=
ionales are
> different.

I do think this discussion is a bit out of the scope of the issue, but I wa=
nted to bring it up because I was writing the proposal with this idea of ma=
king naming rules more uniform. =

If local variable names end up allowing trailing `?`s, I think trailing `!`=
s would be the last remaining difference between local variable names and m=
ethod names. I figured it might be brought up while discussing the issue so=
 I went ahead and mentioned it but I realize now it might just have made th=
e proposal a bit more confusing.

shevegen (Robert A. Heiler) wrote:
> I think this is a backwards-incompatible change so introduction would req=
uire more thought.
I don't see any behaviour this could break in existing code.
What are for now method lookups would turn into variable-or-method lookups,=
 and since it's currently impossible to assign to a `?`-ended variable name=
, it would always default to the method lookup.
Am I missing something here ?

shevegen (Robert A. Heiler) wrote:
> One drawback of this proposal, if implemented, will be that people would =
no longer know
> whether:
> =

>     foo?
> =

> Is a variable; or a method call. Right now they know that it must be a me=
thod call. Again,
> we can see pros/cons either way, but we need to mention cons too.

As can be surely gathered from the beginning of this reply: Where you see a=
 drawback, I see a feature here, and it's actually what's motivating this p=
roposal. Once again, everything is a matter of opinion I guess :-)

--

On the matter of allowing it in instance variable names too, I'm personally=
 against it. An instance variable is clearly different from a method call a=
t first glance. I understand the appeal given the code examples that were s=
hown, but this feels like a mean to an end (`attr_reader :foo?`) and I'm no=
t sure it'd be the best way forward.


----------------------------------------
Feature #15991: Allow questionmarks in variable names
https://bugs.ruby-lang.org/issues/15991#change-79255

* Author: aquaj (J=E9r=E9mie Bonal)
* Status: Open
* Priority: Normal
* Assignee: =

* Target version: =

----------------------------------------
Hi,

I thought such an issue would've already been discussed but no number of se=
arches allowed me to find a similar request. Feel free to close if I missed=
 a previous refusal.

From time to time, especially when trying to clear up complex conditional l=
ogic, I find myself wishing I could add `?` to variable names, since I got =
used to it while naming methods.

For example, currently:
```
if (node? && terminal?) || (halting && (value =3D=3D halting))
  # ...
end
```
becomes
```
last_node =3D self.node? && self.terminal?
halt_on_node =3D halting && (value =3D=3D halting)
if last_node || halt_on_node
  # ...
end
```

`halt_on_node` is clear enough, but `last_node` feels like it would contain=
 a node, instead of expressing its actual purpose ("is the node the last on=
e?").
Right now a developer would have two options as I see them:
1 - extract the conditional to a method `def last_node?` which can be a bit=
 much if it's the only place this code is called.
2 - rename the variable something like `is_last_node`, which feels a bit si=
lly since we're in ruby and used to seeing `?`s for predicates. =


Trying to assign to a questionmarked variable (`a? =3D true`) raises a `Syn=
taxError`. IMHO, it would make for more coherent design to allow it, just l=
ike we do in method names.

I was afraid that `variable?` would be already parsed as beginning a ternar=
y expression (`variable?1:3`) but this isn't parsed either, the only thing =
it's used for is for method calls (`a?5 <=3D=3D> a?(5)`), so this change wo=
uldn't disrupt any current behavior, the expression would just be looked up=
 like any other call instead of only looking up methods.

The only thing I can see with this is that it might raise the issue of allo=
wing `!`s in variable names too, which I'm not sure makes a lot of sense (u=
nlike `?` which denotes "booleanness", a trait shared by variables and meth=
ods alike, I can't see how a variable would be "dangerous").




-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>