Professional Web Applications Themes

Dot versus double-colon - Ruby

OK, I've been thinking (always dangerous after 11 pm). Class-level entities can be accessed via a double-colon. No big mystery: File::open(...) File::SEPARATOR Happily, a class method can also be accessed via a dot: File.open(...) But a constant can't: File.SEPARATOR # syntax error First, why is it this way? Personally, I don't like the :: anyway, as it reminds me of C++. By the way, for those who are wondering, this *is* possible: class File def self.SEPARATOR File::SEPARATOR end end File.SEPARATOR # "/" Even though it looks almost like recursion. Hmm, that raises the question of why/how this works. And another ...

  1. #1

    Default Dot versus double-colon

    OK, I've been thinking (always dangerous after 11 pm).

    Class-level entities can be accessed via a double-colon.
    No big mystery:

    File::open(...)
    File::SEPARATOR

    Happily, a class method can also be accessed via a dot:

    File.open(...)

    But a constant can't:

    File.SEPARATOR # syntax error

    First, why is it this way?

    Personally, I don't like the :: anyway, as it reminds me
    of C++.

    By the way, for those who are wondering, this *is* possible:

    class File
    def self.SEPARATOR
    File::SEPARATOR
    end
    end

    File.SEPARATOR # "/"

    Even though it looks almost like recursion. Hmm, that raises
    the question of why/how this works.

    And another issue is: One *could* write a little module that,
    when included in a class, exposed all the class's constants in
    this way. Within five minutes I had it "almost" working. I'll
    bet someone in another timezone or with more caffeine could
    have it working in three. Anyone?

    Hal


    Hal Fulton Guest

  2. #2

    Default Re: Dot versus double-colon

    Hal Fulton wrote:
    > Even though it looks almost like recursion. Hmm, that raises
    > the question of why/how this works.
    >
    > And another issue is: One *could* write a little module that,
    > when included in a class, exposed all the class's constants in
    > this way. Within five minutes I had it "almost" working. I'll
    > bet someone in another timezone or with more caffeine could
    > have it working in three. Anyone?
    >
    > Hal

    module Dot
    def Dot.append_features( mod )
    mod.constants.each{|c| mod.class_eval( "def self.#{c}() #{mod}::#{c}
    end" ) }
    end
    end

    Hmm....you're right, it is late and this isn't well tested.

    Michael




    Michael Garriss Guest

  3. #3

    Default Re: Dot versus double-colon

    Michael Garriss wrote:
    > Hal Fulton wrote:
    >
    >> Even though it looks almost like recursion. Hmm, that raises
    >> the question of why/how this works.
    >>
    >> And another issue is: One *could* write a little module that,
    >> when included in a class, exposed all the class's constants in
    >> this way. Within five minutes I had it "almost" working. I'll
    >> bet someone in another timezone or with more caffeine could
    >> have it working in three. Anyone?
    >>
    >> Hal
    >
    >
    >
    > module Dot
    > def Dot.append_features( mod )
    > mod.constants.each{|c| mod.class_eval( "def self.#{c}()
    > #{mod}::#{c} end" ) }
    > end
    > end
    >
    Has to be included after all consts are defined......working on that......


    Michael Garriss Guest

  4. #4

    Default Re: Dot versus double-colon

    Michael Garriss wrote:
    > Michael Garriss wrote:
    >
    >> Hal Fulton wrote:
    >>
    >>> Even though it looks almost like recursion. Hmm, that raises
    >>> the question of why/how this works.
    >>>
    >>> And another issue is: One *could* write a little module that,
    >>> when included in a class, exposed all the class's constants in
    >>> this way. Within five minutes I had it "almost" working. I'll
    >>> bet someone in another timezone or with more caffeine could
    >>> have it working in three. Anyone?
    >>>
    >>> Hal
    >>
    >>
    >>
    >>
    >> module Dot
    >> def Dot.append_features( mod )
    >> mod.constants.each{|c| mod.class_eval( "def self.#{c}()
    >> #{mod}::#{c} end" ) }
    >> end
    >> end
    >>
    >
    > Has to be included after all consts are defined......working on that......
    constant_added might help. and fyi, I was trying to use
    define_method rather than eval'ing a string. wonder if
    the techniques are interchangeable?

    I'll worry about it in the morning.

    Hal


    Hal Fulton Guest

  5. #5

    Default Re: Dot versus double-colon

    Hal Fulton wrote:
    > Michael Garriss wrote:
    >
    >> Michael Garriss wrote:
    >>
    >>> Hal Fulton wrote:
    >>>
    >>>> Even though it looks almost like recursion. Hmm, that raises
    >>>> the question of why/how this works.
    >>>>
    >>>> And another issue is: One *could* write a little module that,
    >>>> when included in a class, exposed all the class's constants in
    >>>> this way. Within five minutes I had it "almost" working. I'll
    >>>> bet someone in another timezone or with more caffeine could
    >>>> have it working in three. Anyone?
    >>>>
    >>>> Hal
    >>>
    >>>
    >>>
    >>>
    >>>
    >>> module Dot
    >>> def Dot.append_features( mod )
    >>> mod.constants.each{|c| mod.class_eval( "def self.#{c}()
    >>> #{mod}::#{c} end" ) }
    >>> end
    >>> end
    >>>
    >>
    >> Has to be included after all consts are defined......working on
    >> that......
    >
    >
    > constant_added might help. and fyi, I was trying to use
    > define_method rather than eval'ing a string. wonder if
    > the techniques are interchangeable?
    >
    Not sure. For some reason I never use #define_method. I tend to get a
    little #eval happy sometimes. It was just so exicting when I learned
    about #eval that I have trouble putting it down. I'll have to add
    #define_method (and #constant_added for that matter) to my bag 'o tricks.

    Michael


    Michael Garriss Guest

  6. #6

    Default Re: Dot versus double-colon

    Michael Garriss wrote:
    > Hal Fulton wrote:
    >
    >> Michael Garriss wrote:
    >>
    >>> Michael Garriss wrote:
    >>>
    >>>> Hal Fulton wrote:
    >>>>
    >>>>> Even though it looks almost like recursion. Hmm, that raises
    >>>>> the question of why/how this works.
    >>>>>
    >>>>> And another issue is: One *could* write a little module that,
    >>>>> when included in a class, exposed all the class's constants in
    >>>>> this way. Within five minutes I had it "almost" working. I'll
    >>>>> bet someone in another timezone or with more caffeine could
    >>>>> have it working in three. Anyone?
    >>>>>
    >>>>> Hal
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> module Dot
    >>>> def Dot.append_features( mod )
    >>>> mod.constants.each{|c| mod.class_eval( "def self.#{c}()
    >>>> #{mod}::#{c} end" ) }
    >>>> end
    >>>> end
    >>>>
    >>>
    >>> Has to be included after all consts are defined......working on
    >>> that......
    >>
    >>
    >>
    >> constant_added might help. and fyi, I was trying to use
    >> define_method rather than eval'ing a string. wonder if
    >> the techniques are interchangeable?
    >>
    >
    > Not sure. For some reason I never use #define_method. I tend to get a
    > little #eval happy sometimes. It was just so exicting when I learned
    > about #eval that I have trouble putting it down. I'll have to add
    > #define_method (and #constant_added for that matter) to my bag 'o tricks.
    I think I meant constant_missing. Hmm, *is* there a constant_added??? If
    not, maybe there should be.

    But constant_missing might not be useful here. My brain is *really*
    getting cloudy now.

    I'm the same way. I've overused eval in the past (by some people's
    standards). But now we've got const_[gs]et, instance_variable_[gs]et,
    define_method, and all that coolness. These often obviate the need
    for eval.

    Hal


    Hal Fulton Guest

  7. #7

    Default Re: Dot versus double-colon

    On Sunday, September 14, 2003, 3:04:40 PM, Hal wrote:
    > OK, I've been thinking (always dangerous after 11 pm).
    > Class-level entities can be accessed via a double-colon.
    > No big mystery:
    > File::open(...)
    > File::SEPARATOR
    > Happily, a class method can also be accessed via a dot:
    > File.open(...)
    > But a constant can't:
    > File.SEPARATOR # syntax error
    > First, why is it this way?
    File.open() is sending the message :open to object File. The same
    cannot be said for the constant SEPARATOR.

    > Personally, I don't like the :: anyway, as it reminds me
    > of C++.
    I don't like :: for methods, because . makes sense for method calls on
    objects *and* classes, because .... well, you know why (*).

    :: makes sense for namespaces - as in constant resolution. It would
    not bother me one bit should :: be deprecated for method calls.

    > By the way, for those who are wondering, this *is* possible:
    > class File
    > def self.SEPARATOR
    > File::SEPARATOR
    > end
    > end
    > File.SEPARATOR # "/"
    > Even though it looks almost like recursion. Hmm, that raises
    > the question of why/how this works.
    I'm sure you realise now. It's because you've defined a method :)

    > And another issue is: One *could* write a little module that,
    > when included in a class, exposed all the class's constants in
    > this way. Within five minutes I had it "almost" working. I'll
    > bet someone in another timezone or with more caffeine could
    > have it working in three. Anyone?
    I'm happy for methods and constants to be accessed via different
    mechanisms (message passing vs namespace resolution) and for those
    mechanisms to be syntactically distinct.
    > Hal
    Cheers,
    Gavin


    (*) Classes *are* objects.


    Gavin Sinclair Guest

  8. #8

    Default [OT] Re: Dot versus double-colon


    Hal Fulton wrote:
    > I think I meant constant_missing. Hmm, *is* there a constant_added??? If
    > not, maybe there should be.
    >
    > But constant_missing might not be useful here. My brain is *really*
    > getting cloudy now.
    >
    > I'm the same way. I've overused eval in the past (by some people's
    > standards). But now we've got const_[gs]et, instance_variable_[gs]et,
    > define_method, and all that coolness. These often obviate the need
    > for eval.
    >
    Just had to share this super ugly example from some of my #eval happy code:

    def add_cols( *mods )
    eval(<<CODE
    class << self
    [#{mods.join(',')}].each do |mod|
    name = mod.to_s.sub('Rextra::DB::Col::','')
    eval(eval("Rextra::DB::Col.new_col(name,eval(\\"\# {mod}::NEW_COL\\"
    ))"))
    end
    def new( *args )
    obj = super( *args )
    methods.each do |m|
    method(m).call(obj) if m =~ /^__new_col_/
    end
    obj
    end
    end
    CODE
    )
    end


    Check out the four layers deep eval. Don't ask......

    Michael


    Michael Garriss Guest

  9. #9

    Default Re: Dot versus double-colon

    Gavin Sinclair wrote:
    >>First, why is it this way?
    >
    > File.open() is sending the message :open to object File. The same
    > cannot be said for the constant SEPARATOR.
    Certainly it could be said. In fact, there is no way to tell
    by looking at it whether it is in fact a method or a constant.

    And a constant could be viewed as a method that always returns
    the same value. Uniform access, you know.
    > :: makes sense for namespaces - as in constant resolution. It would
    > not bother me one bit should :: be deprecated for method calls.
    I'm accessing a value within an object. Sure, the value
    happens to be constant. So what?
    >
    >>By the way, for those who are wondering, this *is* possible:
    >
    >
    >> class File
    >> def self.SEPARATOR
    >> File::SEPARATOR
    >> end
    >> end
    >
    >
    >> File.SEPARATOR # "/"
    >
    >
    >>Even though it looks almost like recursion. Hmm, that raises
    >>the question of why/how this works.
    >
    > I'm sure you realise now. It's because you've defined a method :)
    You missed my point. Since the method File.SEPARATOR can be referred
    to by the syntax File::SEPARATOR, then how does the method know that
    it is not calling itself recursively?
    >>And another issue is: One *could* write a little module that,
    >>when included in a class, exposed all the class's constants in
    >>this way. Within five minutes I had it "almost" working. I'll
    >>bet someone in another timezone or with more caffeine could
    >>have it working in three. Anyone?
    >
    >
    > I'm happy for methods and constants to be accessed via different
    > mechanisms (message passing vs namespace resolution) and for those
    > mechanisms to be syntactically distinct.
    I see what you mean. But I say: Why should a constant be anything
    but a reader which happens always to return the same value?

    Hal


    Hal Fulton Guest

  10. #10

    Default Re: Dot versus double-colon

    On Sunday, September 14, 2003, 5:13:04 PM, Hal wrote:
    > Gavin Sinclair wrote:
    >>>First, why is it this way?
    >>
    >> File.open() is sending the message :open to object File. The same
    >> cannot be said for the constant SEPARATOR.
    > Certainly it could be said. In fact, there is no way to tell
    > by looking at it whether it is in fact a method or a constant.
    It "could" be said, but it can't. The interpreter knows whether it's
    a constant, and the capital letter is more than just a convention as
    well - even though SEPERATOR is a valid method name.
    > And a constant could be viewed as a method that always returns
    > the same value. Uniform access, you know.
    Yes, it's appealing. Sometimes I implement "constants" as methods,
    because I want the return value to be regenerated each time. If a
    constant is a hash, its innards can be modified, and it ain't so
    constant anymore. I suppose there's :freeze...

    So your statement above should be qualified: the constant would be a
    method that always returns the same object, not neccesarily the same
    value.
    >> :: makes sense for namespaces - as in constant resolution. It would
    >> not bother me one bit should :: be deprecated for method calls.
    > I'm accessing a value within an object. Sure, the value
    > happens to be constant. So what?
    Sending a message is very different from accessing a value. I
    acknowledge your intentions, though I'm happy the way things are, but
    that fundamental needs to be kept in mind, IMO.

    Just like attr_* are convenient sugar for literal accessor methods,
    are you proposing that "CONSTANT = 1" could/should be sugar for
    creating a method?

    >>
    >>>By the way, for those who are wondering, this *is* possible:
    >>
    >>
    >>> class File
    >>> def self.SEPARATOR
    >>> File::SEPARATOR
    >>> end
    >>> end
    >>
    >>
    >>> File.SEPARATOR # "/"
    >>
    >>
    >>>Even though it looks almost like recursion. Hmm, that raises
    >>>the question of why/how this works.
    >>
    >> I'm sure you realise now. It's because you've defined a method :)
    > You missed my point. Since the method File.SEPARATOR can be referred
    > to by the syntax File::SEPARATOR, then how does the method know that
    > it is not calling itself recursively?
    Presumably the interpreter looks for a constant before a method. This
    may be good luck rather than good management, although the :: may have
    something to do with it.
    > [...]
    Cheers,
    Gavin

    BTW, you could make constants available through dot-notation using
    :method_missing, couldn't you?


    Gavin Sinclair Guest

  11. #11

    Default Re: Dot versus double-colon

    On Sun, Sep 14, 2003 at 04:13:04PM +0900, Hal Fulton wrote:
    > And a constant could be viewed as a method that always returns
    > the same value. Uniform access, you know.
    The problem you identified (infinite recursion) justifies the existence
    of ::. Moreover, :: should be somewhat faster than a normal method
    dispatch.
    > >:: makes sense for namespaces - as in constant resolution. It would
    > >not bother me one bit should :: be deprecated for method calls.
    >
    > I'm accessing a value within an object. Sure, the value
    > happens to be constant. So what?
    I agree w/ Gavin here, I'd be happy to drop the
    SomeClass::singleton_method notation.
    > >>By the way, for those who are wondering, this *is* possible:
    > >
    > >
    > >> class File
    > >> def self.SEPARATOR
    > >> File::SEPARATOR
    > >> end
    > >> end
    > >
    > >
    > >> File.SEPARATOR # "/"
    > >
    > >
    > >>Even though it looks almost like recursion. Hmm, that raises
    > >>the question of why/how this works.
    > >
    > >I'm sure you realise now. It's because you've defined a method :)
    >
    > You missed my point. Since the method File.SEPARATOR can be referred
    > to by the syntax File::SEPARATOR, then how does the method know that
    > it is not calling itself recursively?
    The constant takes precedence over the method when using ::, so no
    recursion.
    > >>And another issue is: One *could* write a little module that,
    > >>when included in a class, exposed all the class's constants in
    > >>this way. Within five minutes I had it "almost" working. I'll
    > >>bet someone in another timezone or with more caffeine could
    > >>have it working in three. Anyone?
    There's a really obvious possible solution:

    batsmantux-chan:/tmp$ expand -t2 i.rb

    if nil

    class Module
    alias_method :_old_method_missing, :method_missing
    def method_missing(meth, *args, &block)
    return const_get(meth) if const_defined? meth
    _old_method_missing
    end
    end

    end

    # or

    module ExposeConstants
    def self.extend_object(mod)
    class << mod;
    alias_method :_old_method_missing, :method_missing
    end
    super
    end

    def method_missing(meth, *args, &block)
    return const_get(meth) if const_defined? meth
    _old_method_missing
    end
    end

    File.extend ExposeConstants

    p File.SEPARATOR

    batsmantux-chan:/tmp$ ruby i.rb
    "/"

    Using method_missing has the following properties:
    * works for constants defined after .extend
    * it's much slower than defining methods for the existent constants
    (that's easy to write too).
    > >I'm happy for methods and constants to be accessed via different
    > >mechanisms (message passing vs namespace resolution) and for those
    > >mechanisms to be syntactically distinct.
    >
    > I see what you mean. But I say: Why should a constant be anything
    > but a reader which happens always to return the same value?
    Speed? It isn't probably the primary reason, however.

    Another benefit is that Ruby can give you a better warning if you redefine
    a constant (you'll get warning: method redefined; discarding old Constant
    in the other case).

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    We come to bury DOS, not to praise it.
    -- Paul Vojta, [email]vojtamath.berkeley.edu[/email]

    Mauricio Fernández Guest

  12. #12

    Default Re: Dot versus double-colon

    Mauricio Fernández wrote:
    > On Sun, Sep 14, 2003 at 04:13:04PM +0900, Hal Fulton wrote:
    >
    >>And a constant could be viewed as a method that always returns
    >>the same value. Uniform access, you know.
    >
    >
    > The problem you identified (infinite recursion) justifies the existence
    > of ::. Moreover, :: should be somewhat faster than a normal method
    > dispatch.
    Well, I guess I'm just being a little irrational here.

    I just happen to dislike :: in every case.

    I think what I'm saying is not "make constants into methods"
    but "make the notations the same (and disallow methods named
    the same as constants)."

    But it's unimportant and there are probably reasons for not
    doing so.
    > The constant takes precedence over the method when using ::, so no
    > recursion.
    Hmm. So if you *wanted* to recurse, you'd have to use the
    dot notation.

    Again it's only an issue because Ruby allows a class to have
    a method and a constant by the same name.

    Here's another thought question. Are all constants class-level?
    Would a singleton constant attached to an object make sense?
    > There's a really obvious possible solution:
    >
    > batsmantux-chan:/tmp$ expand -t2 i.rb
    >
    > if nil
    >
    > class Module
    > alias_method :_old_method_missing, :method_missing
    > def method_missing(meth, *args, &block)
    > return const_get(meth) if const_defined? meth
    > _old_method_missing
    > end
    > end
    >
    > end
    >
    > # or
    >
    > module ExposeConstants
    > def self.extend_object(mod)
    > class << mod;
    > alias_method :_old_method_missing, :method_missing
    > end
    > super
    > end
    >
    > def method_missing(meth, *args, &block)
    > return const_get(meth) if const_defined? meth
    > _old_method_missing
    > end
    > end
    >
    > File.extend ExposeConstants
    >
    > p File.SEPARATOR
    Very good. I'd have seen that if I hadn't failed to see it.
    How's that for a tautology?

    Hal


    Hal Fulton Guest

  13. #13

    Default Re: Dot versus double-colon

    Hal Fulton wrote:
    > Here's another thought question. Are all constants class-level?
    > Would a singleton constant attached to an object make sense?
    To reply to myself:

    3.instance_eval { FOO = 555 }
    puts 3.instance_eval { FOO } # 555

    So it's possible... even for a Fixnum, which can't have
    singletons. :0

    Useful or recommended? Not that I can imagine.

    Hal


    Hal Fulton Guest

  14. #14

    Default Re: Dot versus double-colon

    >>>>> "H" == Hal Fulton <hal9000hypermetrics.com> writes:

    H> 3.instance_eval { FOO = 555 }
    H> puts 3.instance_eval { FOO } # 555

    svg% ruby -e '3.instance_eval { FOO = 555 }; puts 12.instance_eval { FOO }'
    555
    svg%


    Guy Decoux

    ts Guest

  15. #15

    Default Re: Dot versus double-colon

    ts wrote:
    >>>>>>"H" == Hal Fulton <hal9000hypermetrics.com> writes:
    >
    >
    > H> 3.instance_eval { FOO = 555 }
    > H> puts 3.instance_eval { FOO } # 555
    >
    > svg% ruby -e '3.instance_eval { FOO = 555 }; puts 12.instance_eval { FOO }'
    > 555
    > svg%
    Thanks, Guy...

    you.say(so_much) { without_using(any_English) }

    Hal



    Hal Fulton Guest

  16. #16

    Default Re: Dot versus double-colon


    "Hal Fulton" <hal9000hypermetrics.com> wrote in message
    > you.say(so_much) { without_using(any_English) }
    Guy.speaks(ruby)



    Shashank Date Guest

  17. #17

    Default Re: Dot versus double-colon

    Hal Fulton [mailto:hal9000hypermetrics.com] wrote:
    > OK, I've been thinking (always dangerous after 11 pm).
    >
    > Class-level entities can be accessed via a double-colon.
    > No big mystery:
    >
    > File::open(...)
    > File::SEPARATOR
    >
    > Happily, a class method can also be accessed via a dot:
    >
    > File.open(...)
    >
    > But a constant can't:
    >
    > File.SEPARATOR # syntax error
    >
    > First, why is it this way?
    I think because scoping must necessarily have its own notation - consider
    the following:

    class T; end

    class C
    class T; end

    def T; end

    def m
    C.new
    ::T
    end
    end

    If you were to use a '.' in place of the '::' here, you'd end up with an
    ambiguous expression, as the following is perfectly legal:

    C.new
    .T

    There's also the fact that if you eliminated double-colon in favor of dot
    you'd basically have to force all methods to start with a lowercase letter:

    class C
    class T; end
    def T; end
    end

    Should the method T in this case completely replace the class T? What about
    all of the constants nested within T? Of course, since methods starting with
    uppercase letters are generally frowned upon, that might not affect that
    much code, but it would still be a pretty drastic change.

    Now, as for using '::' for calling singleton methods... well, as far as I
    can tell, you can use it for calling _any_ method, singleton or not:

    irb(main):001:0> Object::new::to_s
    => "#<Object:0x2ba4098>"
    irb(main):002:0> Object::new::inspect
    => "#<Object:0x2ba1770>"
    irb(main):003:0> String::new::strip
    => ""
    irb(main):004:0>

    So, if one uses both double-colon and dot in one's code for method access,
    it is necessarily in an arbitrary fashion. For some reason that I do not
    fully understand, I find using '::' for class method access aesthetically
    pleasing:

    String::new

    I tell myself that I like it because it makes the same code tell me more
    about itself at a glance, but I'm not sure about that. I think it might have
    more to do with the fact that it's more consistent looking (to me) when I'm
    chaining constants together to access a class method:

    Test::Unit::UI::Console::TestRunner::run(suite)

    Anyhow, that's my current take on the matter, subject to vacillation at any
    point in the future. I actually just switched over to doing things this way
    a few months back after seeing it in someone else's code.

    > Personally, I don't like the :: anyway, as it reminds me
    > of C++.
    Well, I didn't use to like underscores in method names and local variables,
    but now I find them quite appealing. After that experience I've determined
    to not judge the notation of one language just because it's like (or not
    like) the notation of another language, unless the notation in question has
    serious practical downsides. It wouldn't do to have a language like C++ or
    Java spoiling my Ruby bliss :-)

    > By the way, for those who are wondering, this *is* possible:
    >
    > class File
    > def self.SEPARATOR
    > File::SEPARATOR
    > end
    > end
    >
    > File.SEPARATOR # "/"
    >
    > Even though it looks almost like recursion. Hmm, that raises the question
    of
    > why/how this works.
    From a bit of irb exploration it would appear that this works because '::'
    will always bind to a constant in preference of a method, while '.' is
    guaranteed to bind to a method.

    > And another issue is: One *could* write a little module that, when
    included in a
    > class, exposed all the class's constants in this way. Within five minutes
    I had it
    > "almost" working. I'll bet someone in another timezone or with more
    caffeine could
    > have it working in three. Anyone?
    I guess it reminds me of writing a module to allow one to access all
    under_score methods as camelCase: you can do it (love that Ruby!), but would
    it just confuse folks who read your code? I think I would be confused.

    It's been fun thinking about this... thanks for the brain food, Hal!


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  18. #18

    Default Re: Dot versus double-colon

    Nathaniel Talbott wrote:
    > I think because scoping must necessarily have its own notation - consider
    > the following:
    [snip]

    These are the most compelling reasons I've seen yet. Thanks, Nathaniel.

    It just goes to show that Matz was smarter 11 years ago than I am
    today.
    > It's been fun thinking about this... thanks for the brain food, Hal!
    Not very nourishing, I'm afraid. :)

    Hal


    Hal Fulton Guest

  19. #19

    Default Re: Dot versus double-colon

    > > Personally, I don't like the :: anyway, as it reminds me
    > > of C++.
    >
    > I don't like :: for methods, because . makes sense for method calls on
    > objects *and* classes, because .... well, you know why (*).
    >
    > :: makes sense for namespaces - as in constant resolution. It would
    > not bother me one bit should :: be deprecated for method calls.
    I would not argue against deprecating :: for method calls.

    It seems to me, that in Ruby the "lookup in scope" operation is conceptually
    different from the "send a message" operation. I like that there are two
    different operators for these operations.

    The fact that "::" can also double for the "send a message" operation is
    something I've ignored in the past. In fact, I didn't realize until this
    thread that "::" worked in normal instance method calls, I thought it only
    worked with classes or modules.

    --
    -- Jim Weirich / Compuware
    -- FWP Capture Services
    -- Phone: 859-386-8855

    Weirich, James Guest

Similar Threads

  1. EPS versus PS
    By warren bailey in forum Adobe Acrobat Macintosh
    Replies: 1
    Last Post: September 10th, 10:19 PM
  2. second colon in URL - encoding problem
    By afreed in forum Macromedia Contribute General Discussion
    Replies: 5
    Last Post: July 28th, 06:48 PM
  3. CFX - C versus C++
    By James74 in forum Coldfusion Server Administration
    Replies: 0
    Last Post: July 27th, 08:53 PM
  4. Single versus Double quote marks as string delimiters
    By Joshua Beall in forum PHP Development
    Replies: 12
    Last Post: January 30th, 12:14 PM
  5. ANNOUNCE: Class::Colon 0.02
    By Phil Crow in forum PERL Modules
    Replies: 2
    Last Post: October 8th, 06:50 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139