Access control and class methods

Discussion in 'Ruby' started by Mads Kristensen, Nov 6, 2005.

  1. Hi.

    I was just wondering: does access control not apply to class methods?
    When I use the public, private and protected keywords on my instance
    methods everything works fine, but when I try to do the same on class
    methods they all end up being public anyway.

    A small example:

    --- Snip ---
    #!/usr/bin/ruby

    class Foo
    public
    def Foo._public (x)
    puts "Hello in a public way #{x}"
    end
    protected
    def Foo._protected (x)
    puts "Hello in a protected way #{x}"
    end
    private
    def Foo._private (x)
    puts "Hello in a private way #{x}"
    end
    end

    Foo::_public(1)
    Foo::_protected(2)
    Foo::_private(3)
    --- Snip ---

    Running this small program will call all three methods successfully
    meaning that the private and protected class methods are called from a
    place where _only_ public methods should be available.

    So, are there no access control mechanisms for class methods? Or am i
    missing domething here?

    Best regards,
    Mads D. Kristensen

    BTW: Thanks to the creators of Ruby for a great little language. Good
    work you guys!
     
    Mads Kristensen, Nov 6, 2005
    #1
    1. Advertising

  2. Mads Kristensen

    Trans Guest

    It just doesn't work when done in this way becuase public, private and
    protected are only effecting the incance level, so you need to get to
    the class's "instance level", i.e. the class level.

    class Foo
    class << self
    public
    def _public (x)
    puts "Hello in a public way #{x}"
    end
    protected
    def _protected (x)
    puts "Hello in a protected way #{x}"
    end
    private
    def _private (x)
    puts "Hello in a private way #{x}"
    end
    end
    end

    T.
     
    Trans, Nov 6, 2005
    #2
    1. Advertising

  3. On 11/6/05, Mads Kristensen <> wrote:
    > I was just wondering: does access control not apply to class methods?

    They do but you have to be in the right scope.

    class Bar
    class<<self
    public
    def _public (x)
    puts "Hello in a public way #{x}"
    end
    protected
    def _protected (x)
    puts "Hello in a protected way #{x}"
    end
    private
    def _private (x)
    puts "Hello in a private way #{x}"
    end
    end
    end

    Bar::_public(1)
    Bar::_protected(2)
    Bar::_private(3)
    __END__
    Hello in a public way 1
    C:/rubylib/experiments/ruby-talk/access-control-on-class-methods.rb:40:
    protected method `_protected' called for Bar:Class (NoMethodError)

    Regards

    Sean
     
    Sean O'Halpin, Nov 6, 2005
    #3
  4. Trans wrote:
    > It just doesn't work when done in this way becuase public, private and
    > protected are only effecting the incance level, so you need to get to
    > the class's "instance level", i.e. the class level.


    OK. Thanks a lot for the swift reply.

    But... it seems a bit messy though doesn't it? I mean, if defining a
    class method should be done with the "inner class" syntax you have just
    described to make the access control work, why is it at all possible to
    define a class method using the "ClassName.methodName" syntax?

    Ambiguities like that are no good in programming languages ;-)

    And BTW: what does class<<self actually mean? One < would be inheritance
    but what does it mean when there are two?

    Best regards,
    Mads Kristensen
     
    Mads Kristensen, Nov 6, 2005
    #4
  5. Mads Kristensen

    daz Guest

    Mads Kristensen wrote:
    >
    > And BTW: what does class<<self actually mean? One < would be
    > inheritance but what does it mean when there are two?
    >



    *Nothing* to do with inheritance.

    Check this "archive" thread from 5 Nov 2005:

    http://qurl.net/mO

    (Seems like only yesterday ;)


    daz
     
    daz, Nov 6, 2005
    #5
  6. daz wrote:
    > Check this "archive" thread from 5 Nov 2005:
    >
    > http://qurl.net/mO
    >
    > (Seems like only yesterday ;)


    I'm sorry. I should have done a simple search in this newsgroup ;-)

    Thanks for your reply!

    - Mads
     
    Mads Kristensen, Nov 6, 2005
    #6
  7. Mads Kristensen

    Guest

    On Nov 6, 2005, at 9:47 AM, Mads Kristensen wrote:
    > And BTW: what does class<<self actually mean? One < would be
    > inheritance but what does it mean when there are two?


    One of the early hurdles I had with Ruby was trying to map
    the "class <<object" syntax into a useful mental model. I'm
    not sure why "<<" was selected. The semantics and syntax
    don't seem to be related to those of the "<<" operator and
    so you really need to form two separate mental models and just
    know which one applies.

    Why not something like:

    class obj.eclass
    #
    end

    Where Object#eclass is defined to return the eigenclass of
    the receiver? Even a different keyword would be clearer:

    eclass obj
    #
    end

    It isn't a big deal but it does confuse newbies.


    Gary Wright
     
    , Nov 7, 2005
    #7
  8. wrote:
    >
    > On Nov 6, 2005, at 9:47 AM, Mads Kristensen wrote:
    >
    >> And BTW: what does class<<self actually mean? One < would be
    >> inheritance but what does it mean when there are two?

    >
    >
    > One of the early hurdles I had with Ruby was trying to map
    > the "class <<object" syntax into a useful mental model. I'm
    > not sure why "<<" was selected. The semantics and syntax
    > don't seem to be related to those of the "<<" operator and
    > so you really need to form two separate mental models and just
    > know which one applies.


    Well, it does bear some relation to inheritance which is why,
    I would assume, the syntax was chosen. This...

    class << foobar
    # ...
    end

    ...to me reads something like 'create an unnamed class which
    inherits from foobar' and while not entirely accurate, illustrates
    the basic idea of creating a special class/object based on some
    existing object (foobar above) and defining behaviours on it.

    In actuality, of course, the relationship is inverted as we are
    not inheriting foobar but indeed making foobar inherit from a
    new class but the end result behaves more or less the same.

    > Why not something like:
    >
    > class obj.eclass
    > #
    > end
    >
    > Where Object#eclass is defined to return the eigenclass of
    > the receiver? Even a different keyword would be clearer:
    >
    > eclass obj
    > #
    > end


    There was some debate about what the class should be called
    (I still think #pouch). Also, the irreplaceable _why took it
    upon himself to write a good description of Ruby's metaclasses.

    http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

    There is also a small set of methods towards the bottom to help
    dealing with metaclasses. Wrap it up in a file, put a notice
    thanking _why for his contribution and use it with your code.

    > It isn't a big deal but it does confuse newbies.
    >
    >
    > Gary Wright


    E
     
    Eero Saynatkari, Nov 7, 2005
    #8
  9. Mads Kristensen

    Guest

    On Nov 6, 2005, at 9:45 PM, Eero Saynatkari wrote:
    > class << foobar
    > # ...
    > end
    > [..]
    > In actuality, of course, the relationship is inverted as we are
    > not inheriting foobar but indeed making foobar inherit from a
    > new class but the end result behaves more or less the same.


    This is all part of the confusion. An object is not a subclass
    of its eigenclass so there is no class/subclass relationship
    being asserted by the 'class <<object' syntax. The fact that
    the symbol '<' is *also* used to assert a subclass relationship
    in a similar notation (class A < B) hints at some sort of
    subclassing assertion related to the object that doesn't exist.
    The notation is a semantic head-fake.


    Gary Wright
     
    , Nov 7, 2005
    #9
  10. Mads Kristensen

    zdennis Guest

    wrote:
    >
    > On Nov 6, 2005, at 9:47 AM, Mads Kristensen wrote:
    >
    >> And BTW: what does class<<self actually mean? One < would be
    >> inheritance but what does it mean when there are two?

    >
    >
    > One of the early hurdles I had with Ruby was trying to map
    > the "class <<object" syntax into a useful mental model. I'm
    > not sure why "<<" was selected. The semantics and syntax
    > don't seem to be related to those of the "<<" operator and
    > so you really need to form two separate mental models and just
    > know which one applies.
    >
    > Why not something like:
    >
    > class obj.eclass
    > #
    > end


    Once you know what << does, there is no confusion. I suspect the same would be with your proposed
    code above. By looking at it, I am confused, but once I know what it means, there is no more confusion.

    Zach
     
    zdennis, Nov 7, 2005
    #10
  11. Mads Kristensen

    Guest

    On Nov 6, 2005, at 11:07 PM, zdennis wrote:
    >
    > Once you know what << does, there is no confusion.


    Isn't that a truism?

    As I said in my first post, I found the notation a
    stumbling block for understanding the concept. Based
    on the number of questions about the syntax that show
    up on ruby-talk, I don't think my experience was particularly
    unique.

    > I suspect the same would be with your proposed code above. By
    > looking at it, I am confused, but once I know what it means, there
    > is no more confusion.


    There is a difference between a notation that is not suggestive
    of anything in particular (an "empty vessel") and a notation that
    is suggestive of something that is unrelated.

    In any case, I was just throwing out some ideas for thought.
    Here is another one:

    Ruby currently allows for:

    module M; end
    class Y; end
    class X < Y; end
    class <<x; end

    How about just using

    object x; end

    to open up the singleton class? This sort of goes with my previous
    thought
    that we can think of an object and its eigenclass as simply two views of
    the same object.


    Gary Wright
     
    , Nov 7, 2005
    #11
  12. Selon :

    > >
    > > Once you know what << does, there is no confusion.

    >
    > Isn't that a truism?
    >
    > As I said in my first post, I found the notation a
    > stumbling block for understanding the concept. Based
    > on the number of questions about the syntax that show
    > up on ruby-talk, I don't think my experience was particularly
    > unique.
    >


    Personally, I found the "class << object" *extremely* good at describing =
    the
    concept it referred to. As soon as I understood the *concept*, I found it=
    made
    sense, and helped me not to forget what the concept meant.

    >
    > There is a difference between a notation that is not suggestive
    > of anything in particular (an "empty vessel") and a notation that
    > is suggestive of something that is unrelated.
    >


    I disagree that the notation is suggestive of something unrelated. YMMV.

    > In any case, I was just throwing out some ideas for thought.
    > Here is another one:
    >
    > Ruby currently allows for:
    >
    > module M; end
    > class Y; end
    > class X < Y; end
    > class <<x; end
    >
    > How about just using
    >
    > object x; end
    >
    > to open up the singleton class? This sort of goes with my previous
    > thought
    > that we can think of an object and its eigenclass as simply two views o=

    f
    > the same object.
    >


    Using "object" to open up a *class* is about the most unintuitive thing I=
    've
    ever read. Using a new keyword like "eclass" unjustifiably favours one
    denomination for those classes ("eigenclass") above others, while there i=
    s
    still *no* agreement on how to call them (AFAIK, matz himself still prefe=
    rs to
    call them singleton classes).

    I still don't understand why the "class << object" notation is considered
    unintuitive. I myself read it as "enter the singleton class of the partic=
    ular
    object". "<<" fits the "enter/come in" meaning quite well, and taken that=
    way
    it is pointing in the right direction: you're entering a class.
    --
    Christophe Grandsire.

    http://rainbow.conlang.free.fr

    It takes a straight mind to create a twisted conlang.
     
    Christophe Grandsire, Nov 7, 2005
    #12
  13. Mads Kristensen

    Guest

    On Nov 7, 2005, at 3:36 AM, Christophe Grandsire wrote:
    > I still don't understand why the "class << object" notation is
    > considered
    > unintuitive. I myself read it as "enter the singleton class of the
    > particular
    > object". "<<" fits the "enter/come in" meaning quite well, and
    > taken that way
    > it is pointing in the right direction: you're entering a class.


    And can understand this mental model of the syntax. It is what I've
    come to
    understand also. My point was that it is a *different* mental model
    than
    what I use for:

    class A < B; end.

    The A and B here have different relationship than the object/singleton
    class relationship.


    Gary Wright
     
    , Nov 7, 2005
    #13
  14. Selon :

    >
    > And can understand this mental model of the syntax. It is what I've
    > come to
    > understand also. My point was that it is a *different* mental model
    > than
    > what I use for:
    >
    > class A < B; end.
    >
    > The A and B here have different relationship than the object/singleton
    > class relationship.
    >


    True. That's why you don't use "<" but "<<". Different relationship, diff=
    erent
    syntax. And I don't think the similarity of the two symbols is so close t=
    hat
    it's problematic. I mean, one can write:
    "string" < "other string" and
    "string" << "other string"
    and so far I've never seen someone complain that those two symbols are to=
    o
    similar for the completely different meanings they have. If one can accep=
    t that
    with strings '<' means comparison while '<<' means concatenation, why can=
    not
    they accept that after the keyword 'class' '<' means subclassing while '<=
    <'
    means getting the singleton class?
    --
    Christophe Grandsire.

    http://rainbow.conlang.free.fr

    It takes a straight mind to create a twisted conlang.
     
    Christophe Grandsire, Nov 7, 2005
    #14
  15. Mads Kristensen

    Guest

    On Nov 7, 2005, at 10:06 AM, Christophe Grandsire wrote:
    > If one can accept that with strings '<' means comparison while '<<'
    > means concatenation, why cannot
    > they accept that after the keyword 'class' '<' means subclassing
    > while '<<'
    > means getting the singleton class?


    I can accept it. Semantic overloading happens all the time in
    programming languages and natural languages. It also can be
    confusing during the learning process or if the overloaded definitions
    are only vaguely related. Of course once the overloaded meanings
    have been internalized, it all seems much clearer than it did before.

    Another Ruby example that bit me because of my C and C++ background:
    Kernel#include.
    It took me a long time to get my head around the fact that #include
    is not some
    sort of directive to read and interpret a file. Its behavior isn't
    at all related
    to the #include functionality of C and C++.


    I was poking around to see if there was any historical debate on
    overloading the left shift operator ('<<') for use with IO and then
    by extension with other sorts of concatenation behavior. I found this
    interesting example:


    // Demonstrate shift operators
    #include <iostream>
    using namespace std;

    int main() {
    cout << "5 times 2 is " << (5 << 1) << endl
    << "20 divided by 4 is " << (20 >> 2) << endl;
    }

    The prose around this example neglected to explain that '<<' is used
    in two vastly different ways. This would be pretty difficult
    to digest if you didn't already understand how the semantics of '<<' had
    been overloaded.


    Gary Wright
     
    , Nov 7, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John M. Gabriele
    Replies:
    18
    Views:
    1,175
    Steven Bethard
    Feb 18, 2005
  2. xz
    Replies:
    9
    Views:
    544
    James Kanze
    Jan 8, 2008
  3. Oltmans
    Replies:
    6
    Views:
    360
    Terry Reedy
    Mar 11, 2009
  4. Gioele Barabucci

    Protected methods and class methods

    Gioele Barabucci, Jan 20, 2006, in forum: Ruby
    Replies:
    3
    Views:
    201
    Ross Bamford
    Jan 22, 2006
  5. Kenneth McDonald
    Replies:
    5
    Views:
    345
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page