Random idea - private, blocks, constants

Discussion in 'Ruby' started by Daniel Berger, Dec 13, 2006.

  1. Hi all,

    What do people think of the idea of private (and protected) taking a
    block?

    class Foo
    private do
    SOME_VALUE 88
    def some_method
    7
    end
    end
    end

    This wouldn't really be any different than the current behavior for
    methods, but it would (in theory) allow you to make constants, class
    variables and class instance variables private.

    My main reason for wanting this behavior is that, in some cases, I
    declare constant values that aren't meant for public use.

    A good example is the windows-pr stuff, where I'm converting C macros
    to Ruby values, or using constants to store function pointers from
    Win32API. If you were to do 'require "win32/file"', and then print the
    results of File.constants, you would see dozens of constants, e.g
    File::INVALID_HANDLE_VALUE, File::DeviceIoControl, etc. Most of those
    are not meant for public use and should not be visible directly by the
    end user.

    Come to think of it, perhaps we don't need the block. Just declare
    that anything declared after 'private' is private, including constants,
    etc.

    Or is this concept just too radical?

    Regards,

    Dan

    PS - I thought this had been brought up in the past, but I couldn't
    find anything.
     
    Daniel Berger, Dec 13, 2006
    #1
    1. Advertising

  2. Daniel Berger wrote:
    ...
    > My main reason for wanting this behavior is that, in some cases, I
    > declare constant values that aren't meant for public use.
    >
    > A good example is the windows-pr stuff, where I'm converting C macros
    > to Ruby values, or using constants to store function pointers from
    > Win32API. If you were to do 'require "win32/file"', and then print the
    > results of File.constants, you would see dozens of constants, e.g
    > File::INVALID_HANDLE_VALUE, File::DeviceIoControl, etc. Most of those
    > are not meant for public use and should not be visible directly by the
    > end user.


    What about putting them in a nested module?

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
     
    Joel VanderWerf, Dec 14, 2006
    #2
    1. Advertising

  3. Yukihiro Matsumoto wrote:
    > Hi,
    >
    > In message "Re: Random idea - private, blocks, constants"
    > on Thu, 14 Dec 2006 05:25:11 +0900, "Daniel Berger" <> writes:
    >
    > |What do people think of the idea of private (and protected) taking a
    > |block?
    > |
    > |class Foo
    > | private do
    > | SOME_VALUE 88
    > | def some_method
    > | 7
    > | end
    > | end
    > |end
    > |
    > |This wouldn't really be any different than the current behavior for
    > |methods, but it would (in theory) allow you to make constants, class
    > |variables and class instance variables private.
    > |
    > |My main reason for wanting this behavior is that, in some cases, I
    > |declare constant values that aren't meant for public use.
    >
    > Hmm, first we have to define how private constants (and class
    > variables) behave.
    >
    > Class variables are not supposed to be accessed outside of a class
    > body. So they are always private, I guess. We don't need special
    > treatment for them.


    True.

    > But how should private constants behave? Maybe
    > making them not accessible via :: operator is suffice. I'm not sure
    > yet.


    That seems reasonable, so long as you could still cheat, and get at
    them via const_get if you wanted to (for testing purposes, for
    example). To me that would be roughly analogous to private methods
    that are still accessible via send.

    > The next thing I need to think about is how we can implement them.
    > But it's another story. As far as I can imagine now, it surely is
    > difficult, since currently there's no place to save visibility
    > information in the constants table.


    I poked around in eval.c to see if I could come up with a patch on my
    own, but I think it's beyond me.

    Regards,

    Dan
     
    Daniel Berger, Dec 14, 2006
    #3
  4. Not wanting to troll you here but is this really a problem?

    Adding complexity to the language to hide things but at the same time
    requiring a way to circumvent the protection will achieve very little
    for much work. Remember I could just read the source code and use them
    with const_get.

    If you provide good documentation for your module and the programmers
    have no need to access these constants then they wont. I do all of my
    programming using the docs, as I would guess most of the rest of us do.
    We have better things to do with our time than to dig into your code, we
    have stuff to write.

    And then there is the ego thing. Do you honestly think that you know
    better than every programmer who will ever use your module? There could
    be a real need to get at those constants, you are not omnipotent so just
    document your api and warn the users that if they use anything outside
    of the documented api then on their head be it.

    There is a theory about government that as time passes people will think
    that they should pass some laws or something just to prove their own
    vitality. There seems to come a point in with languages these days that
    people feel that they need to add feature just to show the language is
    alive.

    I blame Microsoft :)

    Again I am not trolling you but I don't see this adding something to
    Ruby that is missing.
     
    Peter Hickman, Dec 14, 2006
    #4
  5. Peter Hickman wrote:
    > Not wanting to troll you here but is this really a problem?
    >
    > Adding complexity to the language to hide things but at the same time
    > requiring a way to circumvent the protection will achieve very little
    > for much work. Remember I could just read the source code and use them
    > with const_get.


    That's fine. I'm not concerned with people getting at my constants if
    they really want to. As things stand now the private/protected
    keywords are are merely advisory anyway. But, they do have their uses.

    > If you provide good documentation for your module and the programmers
    > have no need to access these constants then they wont. I do all of my
    > programming using the docs, as I would guess most of the rest of us do.
    > We have better things to do with our time than to dig into your code, we
    > have stuff to write.


    The digging could end up happening on the outside, not the inside, and
    that's what I'm trying to avoid. Say you're in an irb session and you
    want to see what constants are available for the File class. Normally
    this would just be a handful of values. If you were to do 'require
    "win32/file"', however, you'll end up with a bunch of function pointer
    declarations showing up in the output that you almost certainly don't
    care about. It messes up class inspection.

    > And then there is the ego thing. Do you honestly think that you know
    > better than every programmer who will ever use your module? There could
    > be a real need to get at those constants, you are not omnipotent so just
    > document your api and warn the users that if they use anything outside
    > of the documented api then on their head be it.


    Do you object to the existence of private/protected then? You could
    say the same thing for methods. As I said, private is advisory only,
    but it does have its uses. For example, code coverage automation tools
    could be configured to ignore private methods (which is what I'm
    guessing most of them do by default).

    > There is a theory about government that as time passes people will think
    > that they should pass some laws or something just to prove their own
    > vitality. There seems to come a point in with languages these days that
    > people feel that they need to add feature just to show the language is
    > alive.


    I'm not sure how this makes Ruby more complicated. This adds very
    little mental overhead and I think it would have very little impact on
    existing code, since the majority of Ruby code that I've seen sticks
    the public stuff at the top, and private/protected stuff at the bottom.

    > Again I am not trolling you but I don't see this adding something to
    > Ruby that is missing.


    And that's what public discussion is for. It's just an idea. If Matz
    and/or the majority of folks reading this message think it's stupid (or
    too difficult to implement), then it will be rejected. Otherwise, it
    will be accepted.

    Regards,

    Dan
     
    Daniel Berger, Dec 14, 2006
    #5
  6. Daniel Berger

    Sam Smoot Guest

    Yukihiro Matsumoto wrote:
    > prints 1 and "bar", so that they need not to be protected by
    > visibility. They are, even if they are accepted, just for narrowing
    > constants list.
    >
    > matz.


    In light of that, might the solution here simply be sub-classing the
    objects involved (such as File) instead of decorating the existing
    classes?
     
    Sam Smoot, Dec 15, 2006
    #6
  7. Sam Smoot wrote:
    > Yukihiro Matsumoto wrote:
    >> prints 1 and "bar", so that they need not to be protected by
    >> visibility. They are, even if they are accepted, just for narrowing
    >> constants list.
    >>
    >> matz.

    >
    > In light of that, might the solution here simply be sub-classing the
    > objects involved (such as File) instead of decorating the existing
    > classes?


    Most of the time I would, but there are times when you want to redefine
    methods of existing classes.

    Also, C++ and C# seem to have the concept of private constants. What
    they're used for in practice, though, I'm not sure. I'll have to
    research more.

    Regards,

    Dan
     
    Daniel Berger, Dec 15, 2006
    #7
  8. Daniel Berger wrote:
    > What do people think of the idea of private (and protected) taking a
    > block?
    >
    > This wouldn't really be any different than the current behavior for
    > methods, but it would (in theory) allow you to make constants, class
    > variables and class instance variables private.

    Hrm... I have no opinion on private constants, but I'm going to borrow
    this thread to ask a related question. (Feel free to yell at me.)

    What do people think of 'def' returning the name of the method? Then you
    could do:
    private def foo
    blahblahblah
    end
    For those one-off private methods.

    Devin
    *turns on noise-cancelling headphones*
     
    Devin Mullins, Dec 15, 2006
    #8
  9. Daniel Berger wrote:
    > The digging could end up happening on the outside, not the inside, and
    > that's what I'm trying to avoid. Say you're in an irb session and you
    > want to see what constants are available for the File class. Normally
    > this would just be a handful of values. If you were to do 'require
    > "win32/file"', however, you'll end up with a bunch of function pointer
    > declarations showing up in the output that you almost certainly don't
    > care about. It messes up class inspection.
    >


    Messy yes but is it a problem? Just open another shell and read the
    documentation.

    > Do you object to the existence of private/protected then? You could
    > say the same thing for methods. As I said, private is advisory only,
    > but it does have its uses. For example, code coverage automation tools
    > could be configured to ignore private methods (which is what I'm
    > guessing most of them do by default).
    >


    Actually I would be quite happy with just public and private, I'm not
    sure that I have ever used protected but I'm willing to accept that
    other people find it useful.

    I earn my crust as a Perl programmer and everything is public if you
    used the normal blessed hash technique for objects, Perl objects are
    hack anyway, and guess what - it is not a problem! I realise that for
    anyone from a static background (C/C++/Java/C#) will feel nervous
    without their belt, braces, safety net and lucky rabbit's foot but to be
    honest the problems that all this keyword verbiage protects you against
    is more scaremongering than real. No language, no matter how B&D, will
    stop you from writing bad or broken code. No one will become better a
    programmer because a new keyword is added to the language.
     
    Peter Hickman, Dec 15, 2006
    #9
  10. Devin Mullins wrote:
    > Daniel Berger wrote:
    >> What do people think of the idea of private (and protected) taking a
    >> block?
    >>
    >> This wouldn't really be any different than the current behavior for
    >> methods, but it would (in theory) allow you to make constants, class
    >> variables and class instance variables private.

    > Hrm... I have no opinion on private constants, but I'm going to borrow
    > this thread to ask a related question. (Feel free to yell at me.)
    >
    > What do people think of 'def' returning the name of the method? Then you
    > could do:
    > private def foo
    > blahblahblah
    > end
    > For those one-off private methods.
    >
    > Devin
    > *turns on noise-cancelling headphones*
    >
    >


    This has been proposed before (i.e. have 'def' return a symbol). I
    don't know if Matz implemented this for 1.9 or not. It won't make it
    into 1.8, though.

    http://oldrcrs.rubypal.com/rcr/show/277

    Regards,

    Dan
     
    Daniel Berger, Dec 15, 2006
    #10
  11. Daniel Berger

    Trans Guest

    Yukihiro Matsumoto wrote:
    > Hi,
    >
    > In message "Re: Random idea - private, blocks, constants"
    > on Fri, 15 Dec 2006 04:15:06 +0900, "Daniel Berger" <> writes:
    >
    > |Do you object to the existence of private/protected then? You could
    > |say the same thing for methods. As I said, private is advisory only,
    > |but it does have its uses. For example, code coverage automation tools
    > |could be configured to ignore private methods (which is what I'm
    > |guessing most of them do by default).
    >
    > The demand for private constants are much lower than private methods,
    > since constants are not overridden by subclasses, i.e.
    >
    > class Foo
    > Foo=1
    > def foo
    > p "foo"
    > end
    > def bar
    > p Foo
    > p foo
    > end
    > end
    > class Bar < Foo
    > Foo=2
    > def foo
    > "bar"
    > end
    > end
    > Bar.new.bar
    >
    > prints 1 and "bar", so that they need not to be protected by
    > visibility. They are, even if they are accepted, just for narrowing
    > constants list.


    How does method lookup differ from constant lookup? It has always
    suprised me a little that FOO and FOO() are both legal and different.

    trans.
     
    Trans, Dec 15, 2006
    #11
    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. Arjen
    Replies:
    3
    Views:
    449
    Scott Allen
    Feb 27, 2005
  2. globalrev
    Replies:
    4
    Views:
    774
    Gabriel Genellina
    Apr 20, 2008
  3. matt
    Replies:
    1
    Views:
    274
    George Ogata
    Aug 6, 2004
  4. Krzysztof Loch

    Dynamic variables in blocks vs constants

    Krzysztof Loch, Sep 7, 2010, in forum: Ruby
    Replies:
    2
    Views:
    106
    Krzysztof Lo
    Sep 7, 2010
  5. VK
    Replies:
    15
    Views:
    1,180
    Dr J R Stockton
    May 2, 2010
Loading...

Share This Page