Issue #4877 has been updated by 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.




----------------------------------------
Feature #4877: Unify Variable Expansion within Strings
http://redmine.ruby-lang.org/issues/4877

Author: Lazaridis Ilias
Status: Rejected
Priority: Normal
Assignee: Yukihiro Matsumoto
Category: core
Target version: 


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)






-- 
http://redmine.ruby-lang.org