AClass() vs. AClass[] constuctors (was Best name for "this method")

Discussion in 'Ruby' started by trans. (T. Onoma), Sep 30, 2004.

  1. For reference:
    >
    > class Object
    > def const_get(c)
    > self.class.const_get(c)
    > end
    > def const_set(c,v)
    > self.class.const_set(c,v)
    > end
    > end
    >
    > module Kernel
    > alias method_missing_orig method_missing
    > def method_missing(m,*a,&b)
    > Class === (c = const_get(m)) ? c::new(*a,&b) :
    > method_missing_orig(m,*a,&b)
    > end
    > end


    David wrote:
    > I've lost track of where this is going a bit, but here you seem to be
    > making it look like non-module/class objects have constants:
    >
    >  a = ""
    >  a.const_set("X",1)
    >  p a.const_get("X")   # 1
    >
    > not to mention:
    >
    >  p String::X   # 1
    >
    >(i.e., indirect setting of a Class object's constant).  


    Okay, perhaps they should be private. Beyond that, I'm not sure its really a
    problem since one can just as easily do:

    self.class.const_set

    Yes, this makes it clear that they are class level entities. But the former is
    polymorphic. Perhaps you can show a good use case for why the former is not
    good to have?

    But the above issue aside, this was just the solution I next derived. I'm sure
    there is a more appropriate way to code this method_missing handler --namely
    keeping it in-line with the proper module namespace rules. Perhaps this is
    better:

    class Module
    def method_missing(m,*a,&b)
    Class === (c = const_get(m)) ? c::new(*a,&b) : super
    end
    end

    class Object
    def method_missing(m,*a,&b)
    Class === (c = self.class.const_get(m)) ? c::new(*a,&b) : super
    end
    end

    Better suggestions?

    T.
    trans. (T. Onoma), Sep 30, 2004
    #1
    1. Advertising

  2. Re: AClass() vs. AClass[] constuctors (was Best name for "thismethod")

    Hi --

    On Thu, 30 Sep 2004, trans. (T. Onoma) wrote:

    > For reference:
    > >
    > > class Object
    > > def const_get(c)
    > > self.class.const_get(c)
    > > end
    > > def const_set(c,v)
    > > self.class.const_set(c,v)
    > > end
    > > end
    > >
    > > module Kernel
    > > alias method_missing_orig method_missing
    > > def method_missing(m,*a,&b)
    > > Class === (c = const_get(m)) ? c::new(*a,&b) :
    > > method_missing_orig(m,*a,&b)
    > > end
    > > end

    >
    > David wrote:
    > > I've lost track of where this is going a bit, but here you seem to be
    > > making it look like non-module/class objects have constants:
    > >
    > >  a = ""
    > >  a.const_set("X",1)
    > >  p a.const_get("X")   # 1
    > >
    > > not to mention:
    > >
    > >  p String::X   # 1
    > >
    > >(i.e., indirect setting of a Class object's constant).  

    >
    > Okay, perhaps they should be private. Beyond that, I'm not sure its really a
    > problem since one can just as easily do:
    >
    > self.class.const_set
    >
    > Yes, this makes it clear that they are class level entities. But the former is
    > polymorphic. Perhaps you can show a good use case for why the former is not
    > good to have?


    I'm not sure about a use case; it just doesn't fit the model. Classes
    and modules have constants; other objects, as far as I know, don't.
    Having this kind of transparent delegation makes it seem like they do,
    which is misleading.

    I also wouldn't want non-classes to start having superclasses, class
    methods, etc., just because they have a class. And if I were a Class,
    I wouldn't want all my instances acting like me; I'm an object in my
    own right :)


    David

    --
    David A. Black
    David A. Black, Sep 30, 2004
    #2
    1. Advertising

  3. "David A. Black" <> schrieb im Newsbeitrag
    news:pine.LNX.4.44.0409291852470.2901-100000@wobblini...

    > I'm not sure about a use case; it just doesn't fit the model. Classes
    > and modules have constants; other objects, as far as I know, don't.
    > Having this kind of transparent delegation makes it seem like they do,
    > which is misleading.
    >
    > I also wouldn't want non-classes to start having superclasses, class
    > methods, etc., just because they have a class. And if I were a Class,
    > I wouldn't want all my instances acting like me; I'm an object in my
    > own right :)


    +1

    robert
    Robert Klemme, Sep 30, 2004
    #3
  4. On Wednesday 29 September 2004 09:57 pm, David A. Black wrote:
    > I'm not sure about a use case; it just doesn't fit the model. Classes
    > and modules have constants; other objects, as far as I know, don't.
    > Having this kind of transparent delegation makes it seem like they do,
    > which is misleading.
    >
    > I also wouldn't want non-classes to start having superclasses, class
    > methods, etc., just because they have a class. And if I were a Class,
    > I wouldn't want all my instances acting like me; I'm an object in my
    > own right :)


    Oh, dear. I fear that's taking it quite too far --and very far from the topic,
    which I prefer to focus. As to the avantages and disadvantages of
    class/object polymorphic behavior vs. proper jurisdictions, let us leave for
    another thread. I was never trying to push for those cont_get/set methods
    anyway, they were just an exampled means to an end.

    So back to point. To me the Class[] constructor notation is poor, and Class()
    is much preferable. Note, I am not advocating a replacement for .new(), as I
    think some have taken it. Nor am I suggesting filling-up Kernel space. Nor
    that my example method_missing means is the proper approach. Rather, it would
    simply be a special class constructor that one could define in the classes,
    and would default to Class.new.

    T.
    trans. (T. Onoma), Sep 30, 2004
    #4
  5. "trans. (T. Onoma)" <> schrieb im Newsbeitrag
    news:...

    > So back to point. To me the Class[] constructor notation is poor, and

    Class()
    > is much preferable. Note, I am not advocating a replacement for .new(),

    as I
    > think some have taken it. Nor am I suggesting filling-up Kernel space.


    Fine. :)

    > Nor
    > that my example method_missing means is the proper approach. Rather, it

    would
    > simply be a special class constructor that one could define in the

    classes,
    > and would default to Class.new.


    Just a side note: if I wanted specialized constructors, I'd use class
    instance methods like this:

    class Foo
    def initialize(...)
    ...
    end

    def self.newEmpty()
    allocate
    end

    def self.newBla()
    x = allocate
    x.foo = "bar"
    x
    end
    ...
    end

    But in fact I haven't felt the need for this so far.

    Regards

    robert
    Robert Klemme, Sep 30, 2004
    #5
  6. On Thursday 30 September 2004 09:00 am, Robert Klemme wrote:
    > Just a side note: if I wanted specialized constructors, I'd use class
    > instance methods like this:
    >
    > class Foo
    > def initialize(...)
    > ...
    > end
    >
    > def self.newEmpty()
    > allocate
    > end
    >
    > def self.newBla()
    > x = allocate
    > x.foo = "bar"
    > x
    > end
    > ...
    > end
    >
    > But in fact I haven't felt the need for this so far.


    True 'nuff, and I have done this myself a few times. Nonetheless a number of
    [] constructors exist.

    T.
    trans. (T. Onoma), Oct 1, 2004
    #6
  7. This might be of interest:

    Class [] Method Kernel () Method

    Array x x
    Hash x
    Struct::Tms x
    Dir x
    Float x
    Integer x
    String x
    Binding x*
    Proc x*

    * methods are not capitalized

    So why not make this more consistant, clean up some kernel space, and give
    capitalized methods some legs, with e.g.

    class String
    def self.()(x)
    x.to_s
    end
    end

    T.
    trans. (T. Onoma), Oct 1, 2004
    #7
    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. Alfred E Neuman
    Replies:
    3
    Views:
    263
    Alfred E Neuman
    Nov 4, 2003
  2. Amit_Basnak
    Replies:
    3
    Views:
    323
    =?iso-8859-1?q?Erik_Wikstr=F6m?=
    Jan 11, 2007
  3. tripleF
    Replies:
    2
    Views:
    292
    Marcus Kwok
    Mar 20, 2007
  4. cutecutemouse
    Replies:
    2
    Views:
    355
    cutecutemouse
    Jul 13, 2008
  5. Utku Altinkaya
    Replies:
    0
    Views:
    318
    Utku Altinkaya
    Aug 17, 2008
Loading...

Share This Page