@@vars typesetting bug

ruby-talk
1

Hello
@@x=3 unless @@x
doesnt work as I would expect.

Since it works same for all other varscopes $x .. x, I would classify that
as bug.

Am I wrong?

Berg

2

@@x=3 unless @@x
doesnt work as I would expect.

That's not even a question; how should we know what you expect???

Since it works same for all other varscopes $x .. x, I would classify
that as bug.

Am I wrong?

Most probably.

···

Am 06.03.2016 um 16:10 schrieb A Berger:

3

Hello!

Do I have to explain, what could be expected?!
"set x only if not set yet."
Maybe bugs are issues for experts...

- sure you can do it different.
I just want to point out that is not as one would expect.

Berg

4

Hello
@@x=3 unless @@x
doesnt work as I would expect.

Since it works same for all other varscopes $x .. x, I would classify

that as bug.

Am I wrong?

Berg

Do you have a sample of code that demonstrates it not working?

···

On 07/03/2016 1:11 AM, "A Berger" <aberger7890@gmail.com> wrote:

5

Quit declaring things bugs until you learn the language. It doesn't make sense TO YOU, but you haven't found a bug yet. Too many people have preceded you and found all the easy bugs.

···

On Mar 6, 2016, at 16:15, A Berger <aberger7890@gmail.com> wrote:

Thats the bug.

6

Hello

nothing special:
class A
   def ...
    @@x=9 unless @@x
  end
end
A.xy
interrupts with error, because @@x's type is still not known. - Thats the
bug.

Berg

7

Please don't elide your code or paraphrase exceptions like that. I'm
assuming you meant this:

    class A
      def A.xy
        @@x = 9 unless @@x
      end
    end
    A.xy
    #=> NameError: uninitialized class variable @@x in A

Yes? If so, it's pretty clear that `@@x` should be initialized before it's
used.

    class B
      @@x = nil
      def B.xy
        @@x = 9 unless @@x
      end
    end
    B.xy
    #=> 9

Proper lazy initialisation will work too, if you do it right:

    class C
      def C.xy
        @@x ||= 9
      end
    end
    C.xy
    #=> 9

As to why the exception occurs; that's just how it is. Maybe someone more
knowledgeable about the history of the language can chime in.

Incidentally, you should read this StackOverflow question/answer:

Cheers

···

On 7 March 2016 at 10:15, A Berger <aberger7890@gmail.com> wrote:

Hello

nothing special:
class A
   def ...
    @@x=9 unless @@x
  end
end
A.xy
interrupts with error, because @@x's type is still not known. - Thats the
bug.

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

8

Hi Ryan,
Please tell us why it makes sense (and is not a bug) that class-vars have
the exception that they aren't automatically detected as vars if (maybe)
assigned, and therefore always must be set explicitely, to have them
defined.

I thought it should be the same for all $x .. x types (as one would expect).

Thx Berg

···

Am 07.03.2016 01:20 schrieb "Ryan Davis" <ryand-ruby@zenspider.com>:

> On Mar 6, 2016, at 16:15, A Berger <aberger7890@gmail.com> wrote:
>
> Thats the bug.

Quit declaring things bugs until you learn the language. It doesn't make
sense TO YOU, but you haven't found a bug yet. Too many people have
preceded you and found all the easy bugs.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

9

No.

I'm quite done with your demands and sense of entitlement on this list. MANY of us have asked you time and again to reduce your contribution of noise by doing more and better research before you post to the list. People have pointed you to stackoverflow articles that address your issues directly, refuting your insistence that you've done enough due diligence.

You won't be getting help from me, and I certainly won't be jumping through any hoops for you.

···

On Mar 7, 2016, at 14:37, A Berger <aberger7890@gmail.com> wrote:

Please tell us why it makes sense (and is not a bug) that class-vars have the exception that they aren't automatically detected as vars if (maybe) assigned, and therefore always must be set explicitely, to have them defined.

10

What does "$x .. x types" mean?

···

On Mon, Mar 07, 2016, A Berger wrote:

Hi Ryan,
Please tell us why it makes sense (and is not a bug) that class-vars have
the exception that they aren't automatically detected as vars if (maybe)
assigned, and therefore always must be set explicitely, to have them
defined.

I thought it should be the same for all $x .. x types (as one would expect).

--
        Eric Christopherson

11

As was mentioned before, "unless @@x" (or unless x, or any number of other
things) doesn't actually check if something is defined, it just just checks
if it's not false. In some cases, that's fine because the default is nil,
but you really should be using 'unless defined?(@@x)'.

In all cases, if the variable isn't defined, you get 'nil' from 'defined?'.
Consistently.

In the version of ruby that I'm running, I get 'nil' for calls to $x and
@x, but exceptions for just x or @@x. So any claim about it being the same
for everything except @@x is incorrect.

Don't depend on weird behaviors. Ever.

Just use 'defined?'.

If you need to make sure it's also not nil, use defined?(<var>) && !
<var>.nil?

···

On Mon, Mar 7, 2016 at 2:37 PM A Berger <aberger7890@gmail.com> wrote:

Hi Ryan,
Please tell us why it makes sense (and is not a bug) that class-vars have
the exception that they aren't automatically detected as vars if (maybe)
assigned, and therefore always must be set explicitely, to have them
defined.

I thought it should be the same for all $x .. x types (as one would
expect).

Thx Berg
Am 07.03.2016 01:20 schrieb "Ryan Davis" <ryand-ruby@zenspider.com>:

> On Mar 6, 2016, at 16:15, A Berger <aberger7890@gmail.com> wrote:
>
> Thats the bug.

Quit declaring things bugs until you learn the language. It doesn't make
sense TO YOU, but you haven't found a bug yet. Too many people have
preceded you and found all the easy bugs.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

12

As was mentioned before, "unless @@x" (or unless x, or any number of other
things) doesn't actually check if something is defined, it just just checks
if it's not false. In some cases, that's fine because the default is nil,
but you really should be using 'unless defined?(@@x)'.

Why? What for?

In all cases, if the variable isn't defined, you get 'nil' from 'defined?'.
Consistently.

Exactly.

Don't depend on weird behaviors. Ever.

+1

Just use 'defined?'.

I still have to see a case where defined? is needed. For local
variables the result will never change until you change code because
it is determined at compile time when something is defined.

$ ruby x.rb
nil
"local-variable"
nil
"local-variable"
$ cat -n x.rb
     1
     2 def x(a)
     3 p defined?(y)
     4 if a
     5 y = nil
     6 end
     7 p defined?(y)
     8 end
     9
    10 x true
    11 x false
    12

If you need to make sure it's also not nil, use defined?(<var>) && !
<var>.nil?

This is really unnecessary complicated. Can you show an example where
defined? really makes sense?

Cheers

robert

···

On Mon, Mar 7, 2016 at 11:56 PM, James Pacheco <james.pacheco@gmail.com> wrote:

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

13

Hi Ryan

...

> Don't depend on weird behaviors. Ever.

+1

So thats what Im speaking about.
In some cases you need defined? (to avoid an exception), in other you can
easily just test for nil.
It's not consistent. - Must there be such things in Ruby?
Some say 'weird behaviour', I asked if it may be a bug. Whats the
difference?

I think its of interest for all, why this behaviour makes sense ("to you")!

Regardless the above I would say defined? would make much more sense if
derived at runtime (especially for methods!).
I don't know if it is possible to change that.

Thanks
Berg

···

Am 08.03.2016 09:03 schrieb "Robert Klemme" <shortcutter@googlemail.com>:

On Mon, Mar 7, 2016 at 11:56 PM, James Pacheco <james.pacheco@gmail.com> wrote:

14

...

> Don't depend on weird behaviors. Ever.

+1

So thats what Im speaking about.
In some cases you need defined? (to avoid an exception),

In which cases?

in other you can
easily just test for nil.
It's not consistent. - Must there be such things in Ruby?

No, they do not need to be in Ruby. Here's the news: Ruby, as any
human artifact, has flaws. And: there is a cost attached to them - but
also to removing them. And some are not actually flaws.

Some say 'weird behaviour', I asked if it may be a bug. Whats the
difference?

A bug is unintended behavior. Weird != unintended

I think its of interest for all, why this behaviour makes sense ("to you")!

I think you may be wrong here.

robert

···

On Tue, Mar 8, 2016 at 11:26 AM, A Berger <aberger7890@gmail.com> wrote:

Am 08.03.2016 09:03 schrieb "Robert Klemme" <shortcutter@googlemail.com>:

On Mon, Mar 7, 2016 at 11:56 PM, James Pacheco <james.pacheco@gmail.com> >> wrote:

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

15

​gvars can be defined and inspected anywhere, at any time, so it makes
sense to be forgiving when accessing them.

lvars are identified by the interpreter when parsing, so the concept of an
undefined lvar is nonsensical, especially at runtime.

ivars can be accessed without ever touching an at-symbol (let alone
explicitly assigning to them), for example:

    class Foo
      attr_reader :bar
    end
    Foo.new.bar

so it makes sense to have those implicitly default to nil.

cvars can only be accessed inside the class definition (unlike gvars), are
defined and given value at runtime (unlike lvars), and can only be accessed
using the @@ sigil (unlike ivars). Trying to force "consistency" on these
completely inconsistent concepts is misled at best.

Additionally: cvars are relatively risky compared to other scoped variables
(they are long-lived and occupy an unusual scope); it's really easy to
accidentally double-tap @ when you're trying to access an ivar and end up
with a hard-to-identify bug; and it's unbelievably simple to initialize
them:

    class Bar
      @@baz = nil # unbelievably simple
    end

so there's two arguments for why it's not worth the effort of adding the
default nil behaviour, and one argument for why it's actually better to
raise an exception.

Can we please move on now?

···

On 8 March 2016 at 20:26, A Berger <aberger7890@gmail.com> wrote:

Hi Ryan

Am 08.03.2016 09:03 schrieb "Robert Klemme" <shortcutter@googlemail.com>:
>
> On Mon, Mar 7, 2016 at 11:56 PM, James Pacheco <james.pacheco@gmail.com> > wrote:
...
> > Don't depend on weird behaviors. Ever.
>
> +1

So thats what Im speaking about.
In some cases you need defined? (to avoid an exception), in other you can
easily just test for nil.
It's not consistent. - Must there be such things in Ruby?

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

16

Oh, and I forgot constants. Those also raise an exception when undefined.

And another afterthought: warnings. Undefined gvars and ivars emit a
warning when $VERBOSE is set. So it's acknowledged that there is a
difference between 'undefined' and 'defined but nil.'

This is not a simple space, and there is no perfect solution. Aesthetic
symmetry certainly isn't it.

···

On 8 March 2016 at 23:48, Matthew Kerwin <matthew@kerwin.net.au> wrote:

On 8 March 2016 at 20:26, A Berger <aberger7890@gmail.com> wrote:

In some cases you need defined? (to avoid an exception), in other you can
easily just test for nil.
It's not consistent. - Must there be such things in Ruby?

​gvars can be defined and inspected anywhere, at any time, so it makes
sense to be forgiving when accessing them.

lvars are identified by the interpreter when parsing, so the concept of an
undefined lvar is nonsensical, especially at runtime.

ivars can be accessed without ever touching an at-symbol (let alone
explicitly assigning to them), for example:

    class Foo
      attr_reader :bar
    end
    Foo.new.bar

so it makes sense to have those implicitly default to nil.

cvars can only be accessed inside the class definition (unlike gvars), are
defined and given value at runtime (unlike lvars), and can only be accessed
using the @@ sigil (unlike ivars). Trying to force "consistency" on these
completely inconsistent concepts is misled at best.

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/