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

ruby-talk
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.

2

Hi --

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 :slight_smile:

David

···

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

--
David A. Black
dblack@wobblini.net

3

"David A. Black" <dblack@wobblini.net> 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 :slight_smile:

+1

    robert

4

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.

···

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 :slight_smile:

5

"trans. (T. Onoma)" <transami@runbox.com> schrieb im Newsbeitrag
news:200409300747.00023.transami@runbox.com...

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. :slight_smile:

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

6

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

T.

···

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.

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.