Feature #4877: Unify Variable Expansion within Strings

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[lazaridis.com (Lazaridis Ilias)]

class VarTester
$g = "global"
@@c = "class"

def f
"function"
end

def initialize
@i = "instance"
l = "local"
puts "#$g #@@c #@i #l #f #{l} #{f}"
end
end

VarTester.new

#=> global class instance #l #f local function

=== User Context ===

3 variable types (Class- instance- and global) can be expanded by prefixing a single char ("#") (without the need to add "{}").

This should be enabled for local vars and ideally for functions, too (at least the attr accessors).

=== Pro ===

• consistent expansion of all variable types via "#"
• reduced typing (use of {} is optional)
• increased readability of strings which contain many variables.

=== Contra ===

?

=== Compatibility ===

This would break slightly existent behaviour:

existent '#text' within strings would be expanded (should be a rare case)

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)

[matz (Yukihiro Matsumoto)]

• Status changed from Assigned to Rejected

Expanding non-prefixed variables/expressions are too easy to conflict. For example, you will have problem to print a string like "Foo#bar". It would print "Foonil" or whatever depends on the value of the local variable bar. For me, that is annoying too much.

[lazaridis.com (Lazaridis Ilias)]

Yukihiro Matsumoto wrote:

Expanding non-prefixed variables/expressions are too easy to conflict. For example, you will have problem to print a string like "Foo#bar". It would print "Foonil" or whatever depends on the value of the local variable bar. For me, that is annoying too much.

I understand this, but:

• a typical user does not use "Class#method" often.
• Even if, he could simply uses "Class#method".

Subjecting the issue-processing:

why are you so eager to "reject" immediately? I understand that "Rejected" means that the issue topic is closed, and it will not dealt with.

But the issue topic is "Unify Variable Expansion within Strings", is a good goal, for the users benefit. And it can happen in other ways, too.

Examples are:

• puts "#$g #@@c #@i ##l ##f" (typing "#" twice is still very fast)
• puts "~$g ~@@c ~@i ~l ~f" (unify variable expansion based on another char, usual way via # and #{} remains)

There are other possible ways, but with a "rejected" you discourage any discussion.

[Skade (Florian Gilcher)]

"#test" is used very often, especially in many test suites out there, as it is the notation used for instance methods in Ruby. So changing this would break a lot of code, for example: https://github.com/datamapper/dm-core/blob/master/spec/unit/mash_spec.rb.

[aprescott (Adam Prescott)]

On Mon, Jun 13, 2011 at 11:07 AM, Lazaridis Ilias [e-mail] wrote:

Yukihiro Matsumoto wrote:

Expanding non-prefixed variables/expressions are too easy to conflict.  For example, you will have problem to print a string like "Foo#bar".  It would print "Foonil" or whatever depends on the value of the local variable bar.  For me, that is annoying too much.

Completely agree.

I understand this, but:
 * a typical user does not use "Class#method" often.
 * Even if, he could simply uses "Class#method".

This is a lousy work-around for a problem created by a solution to a
non-problem.

Subjecting the issue-processing:

why are you so eager to "reject" immediately? I understand that "Rejected" means that the issue topic is closed, and it will not dealt with.

As you're a stickler for staying on-topic, what are your comments on
issue processing doing here?

But the issue topic is "Unify Variable Expansion within Strings", is a good goal, for the users benefit. And it can happen in other ways, too.

Examples are:

 * puts "#$g #@@c #@i ##l ##f" (typing "#" twice is still very fast)
 * puts "~$g ~@@c ~@i ~l ~f"   (unify variable expansion based on another char, usual way via # and #{} remains)

#{l} is cleaner and more readable for me than ##l. And you still
introduce potential conflicts with existing code which has strings
involving "~" and "##".

There are other possible ways, but with a "rejected" you discourage any discussion.

Please remain professional and on-topic.

[lazaridis.com (Lazaridis Ilias)]

Florian Gilcher wrote:

"#test" is used very often, especially in many test suites out there, as it is the notation used for instance methods in Ruby. So changing this would break a lot of code, for example: https://github.com/datamapper/dm-core/blob/master/spec/unit/mash_spec.rb.

I understand, this sounds like a valid reason.

Still, there are other options to "Unify Variable Expansion within Strings" (see examples, added a new one).

• puts "Expand #$g, #@@c and #@i - similar to #{l} and #{f}." (current status)

• puts "Expand #$g, #@@c and #@i - similar to ##l and ##f." (double "#" - expansion marker & pseudo prefix)

• puts "Expand ~$g, ~@@c and ~@i - similar to ~l and ~f." (another char, usual way via # and #{} remains)

• puts "Expand {$g}, {@@c} and {@i} - similar to {l} and {f}." (omit the # char)

[matz (Yukihiro Matsumoto)]

Hi,

In message "Re: [ruby-core:37079] [Ruby 1.9 - Feature #4877] Unify Variable Expansion within Strings"
on Mon, 13 Jun 2011 19:07:44 +0900, Lazaridis Ilias [e-mail] writes:
|
|I understand this, but:
| * a typical user does not use "Class#method" often.
| * Even if, he could simply uses "Class#method".
|
|Subjecting the issue-processing:
|
|why are you so eager to "reject" immediately? I understand that "Rejected" means that the issue topic is closed, and it will not dealt with.

Firstly, for most of the cases, you are not the first one to come up
with the idea like this. I have already considered the idea long
before you proposed.

Secondly, most quick-rejected proposals introduce incompatibility,
with which the feature would less likely be accepted.

						matz.

[lazaridis.com (Lazaridis Ilias)]

Yukihiro Matsumoto wrote:

Hi,

In message "Re: [ruby-core:37079] [Ruby 1.9 - Feature #4877] Unify Variable Expansion within Strings"
on Mon, 13 Jun 2011 19:07:44 +0900, Lazaridis Ilias [e-mail] writes:
|
|I understand this, but:
| * a typical user does not use "Class#method" often.
| * Even if, he could simply uses "Class#method".
|
|Subjecting the issue-processing:
|
|why are you so eager to "reject" immediately? I understand that "Rejected" means that the issue topic is closed, and it will not dealt with.

Firstly, for most of the cases, you are not the first one to come up
with the idea like this.

I assumed this, and it's just a reason more to give this issue more attention.

I have already considered the idea long before you proposed.

Is this documented somewhere (thus one can see the rationales)?

Secondly, most quick-rejected proposals introduce incompatibility,
with which the feature would less likely be accepted.

I understand this, but the proposal was not a final one. It was an initial one.

The one thing which should be clear is, that "Unify Variable Expansion within Strings" is something which would make the language better. Rejecting this is like saying: "Everything is fine with variable expansion".

But it's not.

• It starts with the usage of "#", which is the comment char.
• Then there is the inconsistency of it's usage.
• The only consistent way is the 3-char-way "#{}" (sometimes more overhead than the var name).
• and most important: currently, there is no way to alter this behaviour, as it is in c-core-level.

All this should be enough to leave this issue open, thus possibly a solution comes up. Even if you place it on "1.9.x" or even the 2.0 line (where I assume some incompatibility is tolerated more).

I think that's the Status:"Feedback" (although this can take quite a while). But who knows, possibly someone comes up with a full compatible solution.

It's like saying: "Yes, we have an issue here, something has to be done".

[wishdev (John Higgins)]

It always happens - you give someone enough rope and they always end up with it wrapped around their neck.....

Lazaridis Ilias wrote:

The one thing which should be clear is, that "Unify Variable Expansion within Strings" is something which would make the language better. Rejecting this is like saying: "Everything is fine with variable expansion".

But it's not.

• It starts with the usage of "#", which is the comment char.

So why then are you suggesting to use # as the start of your grand unified system?

• Then there is the inconsistency of it's usage.
• The only consistent way is the 3-char-way "#{}" (sometimes more overhead than the var name).

How can it be inconsistent and consistent at the same time?

• and most important: currently, there is no way to alter this behaviour, as it is in c-core-level.

If that's the most important thing in the world - why not request that option? You have not done that at all here - you have rambled on about something that has no bearing on whether or not it can be changed. In fact you have simply advocated for another way of doing #{} - no where until that very line had you even mentioned the concept of having it changeable on the fly. Running out of steam and grasping for anything you can?

All this should be enough to leave this issue open, thus possibly a solution comes up. Even if you place it on "1.9.x" or even the 2.0 line (where I assume some incompatibility is tolerated more).

There is nothing there at all to leave this issue open.

I think that's the Status:"Feedback" (although this can take quite a while). But who knows, possibly someone comes up with a full compatible solution.

It's like saying: "Yes, we have an issue here, something has to be done".

Except we do not have an issue here.

[lazaridis.com (Lazaridis Ilias)]

John Higgins wrote:

It always happens - you give someone enough rope and they always end up with it wrapped around their neck.....

Lazaridis Ilias wrote:

The one thing which should be clear is, that "Unify Variable Expansion within Strings" is something which would make the language better. Rejecting this is like saying: "Everything is fine with variable expansion".

But it's not.

• It starts with the usage of "#", which is the comment char.

So why then are you suggesting to use # as the start of your grand unified system?

Obvious: compatibility

Obvious: there are other suggestions within the comments.

• Then there is the inconsistency of it's usage.
• The only consistent way is the 3-char-way "#{}" (sometimes more overhead than the var name).

How can it be inconsistent and consistent at the same time?

Obvious:

• first point refers to the single-char usage ("#") (inconsistent, does not work for locals and functions)
• second point tho the 3-char-way "#{}" (consistent, works for everything)

• and most important: currently, there is no way to alter this behaviour, as it is in c-core-level.

If that's the most important thing in the world - why not request that option?
[...]

Obvious: The Object Model of the language would allow me to alter the behaviour
Obvious: It breaks with literal instantiation
Obvious: I've asked already for a construct which would allow alternate Variable Expansion behaviour (see #4845)
Obvious: The same technical difficulty would exist for a direct way, thus I didn't ask.

All this should be enough to leave this issue open, thus possibly a solution comes up. Even if you place it on "1.9.x" or even the 2.0 line (where I assume some incompatibility is tolerated more).

There is nothing there at all to leave this issue open.

Obvious: you cannot see.

The technical difficulty of those issues is quite high, as you see from the amount of obvious things you had overseen.

I think that's the Status:"Feedback" (although this can take quite a while). But who knows, possibly someone comes up with a full compatible solution.

It's like saying: "Yes, we have an issue here, something has to be done".

Except we do not have an issue here.

There is an issue, even Mr. Matsumoto admit this:

" Firstly, for most of the cases, you are not the first one to come up with the idea like this."
"I have already considered the idea long before you proposed."

Which means there were user requests which he had considered (but a solution was not yet found).

So, it ends up to be more an organizational decision, e.g. if I have to open a new issue for every suggestion, or if this issue can stay open to collect interest, information and suggestions.

One final thing:

May I ask you to refrain from further comments in such a tenor? You may want to write your personal stuff on the user group. There's even a dedicated topic there. The quality of the issue-tracking-system here is exceptionally high and the issues remain usually strictly in topic and technical. It would be a shame to degrade this quality.