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

[trans. (T. Onoma)]

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

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.

 

[David A. Black]

Hi --

For reference:


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

 

[Robert Klemme]

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

 

[trans. (T. Onoma)]

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.

 

[Robert Klemme]

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

 

[trans. (T. Onoma)]

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)]

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.