Why the lack of mixing-in support for Class methods?


#161

On 6/15/06, Yukihiro M. removed_email_address@domain.invalid wrote:

|Thankfully all the important ones (except #dup
|and #clone) start with either ‘__’ or ‘instance_’ (eg. send). But
|#funcall will add another exception. It would be nicer to see a
|consistant pattern in the naming of these meta-methods.
Good point. We will have funcall as well. Thank you.

Should we have dup and clone and class and object_id?

I am already using #send in preference to #send when I need the
functionality, but it would be nice to know that for those methods we
literally cannot get along without … we have access to without
rebind hacks.

-austin


#162

Hi,

In message “Re: Why the lack of mixing-in support for Class methods?”
on Fri, 16 Jun 2006 02:01:53 +0900, removed_email_address@domain.invalid writes:

|I see. I wouldn’t otherwise have a problem with the name ‘funcall’ but
|it’s a meta-programming method and as such it’s something important to
|always have available. I have BasicObject class (basically the same as
|BlankSlate) which clears out the Kernel methods. But some methods are
|too important to remove. Thankfully all the important ones (except #dup
|and #clone) start with either ‘__’ or ‘instance_’ (eg. send). But
|#funcall will add another exception. It would be nicer to see a
|consistant pattern in the naming of these meta-methods.

Good point. We will have funcall as well. Thank you.

						matz.

#163

On Jun 15, 2006, at 11:40 PM, Austin Z. wrote:

Should we have dup and clone and class and object_id?

I am already using #send in preference to #send when I need the
functionality, but it would be nice to know that for those methods we
literally cannot get along without … we have access to without
rebind hacks.

I can definitely see class and object_id. #dup and #clone
though it seems to me that there would be plently of situations that
someone would want to override those, and you would want the
overridden versions. Failing that maybe add a #copy method that would
default to an alias of #dup but would be for the express purpose of
overriding for “deeper” copies. I guess it’s a judgement call. (One I
thankfully don’t have to make).


#164

Austin Z. wrote:

functionality, but it would be nice to know that for those methods we
literally cannot get along without … we have access to without
rebind hacks.

I agree. And I did add class in basic object, though I find it’s
not so often needed b/c of ‘X === x’. Nonetheless it certainly seems
like one of the fundamentals. BTW, we have id already, so I don’t
think object_id is needed.

I’ve also expiremented with two other methods, #self (alias
#object) which is a Functor that binds subsequent calls to Object. Eg.
x.self.class will return the class of x even if x.class won’t. I
took it a step further with #as / #as, in which one can specify
which ancestor to bind to instead of just Object.
x.as(Enumerble).each, for instance.

Food for thought.

T.


#165

Hi –

On Fri, 16 Jun 2006, Yukihiro M. wrote:

| class_extension{ attr_accessor ‘a’ }
p M.a # => 42
Will this happen if the module is included in another module? If so,
I’m wondering whether a more generic name, without “class” in it,
could be used instead of “class_extension”.

David


David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

See what the readers are saying about “Ruby for Rails”!
http://www.rubypowerandlight.com/quotes


#166

Logan C. wrote:

I can definitely see class and object_id. #dup and #clone
though it seems to me that there would be plently of situations that
someone would want to override those, and you would want the
overridden versions. Failing that maybe add a #copy method that would
default to an alias of #dup but would be for the express purpose of
overriding for “deeper” copies. I guess it’s a judgement call. (One I
thankfully don’t have to make).

Of course dup and clone can be overridden too. But I imagine
that would create quite a bit of additional work, so maybe these two
are just better left as exceptions …not sure.

T.


#167

Hi,

In message “Re: Why the lack of mixing-in support for Class methods?”
on Fri, 16 Jun 2006 18:56:23 +0900, removed_email_address@domain.invalid writes:

|> class C
|> include M
|> end
|> M.a = 42
|> p M.a # => 42
|
|Will this happen if the module is included in another module? If so,
|I’m wondering whether a more generic name, without “class” in it,
|could be used instead of “class_extension”.

That’s where I am wondering. Using the Daniel’s code:

module M
class_extension do
def foo
end
end
end
module M2
include M
end
class C
include M2
end

M.foo # => NoMethodError
M2.foo # => Error? (should it affect modules?)
C.foo # => Error? (should class_extension be propagated?)

If ‘class_extension’ affects modules as well, do you think of any
more generic name, in place of “class” extension?

						matz.

#168

Yukihiro M. wrote:

include M2

end

M.foo # => NoMethodError
M2.foo # => Error? (should it affect modules?)

No, the class extension should be included into both modules and
classes. I think this’ll get too complex otherwise, with users wondering
why #include works differently in classes and modules.

C.foo # => Error? (should class_extension be propagated?)

I’m not sure on that one, though I’d default to say yes, it should be
propagated.

If ‘class_extension’ affects modules as well, do you think of any
more generic name, in place of “class” extension?

I temporarily used #metamodule or something similar, as I saw the class
extension as a “module above the module”, that got included into the
“class above the class”. That may be rubbish, but it’s how I think of
it.

Cheers,
Daniel


#169

Yukihiro M. wrote:

|
end
end
module M2
include M
end
class C
include M2
end

M.foo # => NoMethodError
M2.foo # => Error? (should it affect modules?)

I’d say yes.

C.foo # => Error? (should class_extension be propagated?)

I’d say no, but maybe there should be another function to import it.

module M
class_extension do
def foo
end
end
end
module M2
include_class_extension M
end
module M3
include M2
end

M.foo #=> error
M2.foo #=> error
M3.foo #=> no error

If ‘class_extension’ affects modules as well, do you think of any
more generic name, in place of “class” extension?

module_extension, included_module_features, define_module_features, …?


#170

Yukihiro M. wrote:

M2.foo # => Error? (should it affect modules?)

If ‘class_extension’ affects modules as well, do you think of any
more generic name, in place of “class” extension?

The name is not really incorrect because

class << Module.new ; self.class ; end #=> Class

C.foo # => Error? (should class_extension be propagated?)

It needs to propagate. Otherwise it defeats much of the purpose.
Without propapation we could not create module adapters, or use #super,
which is absolutely vital when using it to track meta information, like
a method annotation for example.

T.


#171

Heh, soon we’ll end up adding other * methods for the sake of it.

I don’t see this as a benefit, and I’ve never really got down and
said, “Gee, I wish this method wasn’t overridable!”, and if I have, it
would have been for send' which was easily remedied withsend’.

Also, for #object_id, there’s already a #id.


#172

removed_email_address@domain.invalid wrote:

If ‘class_extension’ affects modules as well, do you think of any more
generic name, in place of “class” extension?

singleton_methods &block

Except it’s not restricted to methods. Here’s a couple of spinoffs:

  • singleton_module
  • singleton_extension

Cheers,
Daniel


#173

Daniel S. wrote:

Eeek! Please, no “singleton”. Anything but “singleton”.

T.


#174

On Fri, 16 Jun 2006, Yukihiro M. wrote:

end
class C
include M2
end

M.foo # => NoMethodError
M2.foo # => Error? (should it affect modules?)
C.foo # => Error? (should class_extension be propagated?)

If ‘class_extension’ affects modules as well, do you think of any more
generic name, in place of “class” extension?

singleton_methods &block

-a


#175

On Sat, 17 Jun 2006 removed_email_address@domain.invalid wrote:

Eeek! Please, no “singleton”. Anything but “singleton”.

what’s wrong with singleton? alternatives?

-a


#176

On Jun 16, 2006, at 11:43 AM, removed_email_address@domain.invalid wrote:

On Sat, 17 Jun 2006 removed_email_address@domain.invalid wrote:

Eeek! Please, no “singleton”. Anything but “singleton”.

what’s wrong with singleton? alternatives?

Uh oh. Here we go again…

Gary W.


#177

removed_email_address@domain.invalid wrote:

Eeek! Please, no “singleton”. Anything but “singleton”.

`beer_module’?


#178

On 6/16/06, Christian N. removed_email_address@domain.invalid wrote:

module would probably be better.
I could get behind that. Probably worth an RCR, I think.

-austin


#179

“Austin Z.” removed_email_address@domain.invalid writes:

On 6/15/06, Yukihiro M. removed_email_address@domain.invalid wrote:

|Thankfully all the important ones (except #dup
|and #clone) start with either ‘__’ or ‘instance_’ (eg. send). But
|#funcall will add another exception. It would be nicer to see a
|consistant pattern in the naming of these meta-methods.
Good point. We will have funcall as well. Thank you.

Should we have dup and clone and class and object_id?

Instead of further pythonizing the language (sorry, couldn’t resist),
I’d rather prefer a non-OO way for the tricky cases:

Object.object_id_of myobj
Object.class_of myobj
Object.send_to myobj, :foo

Maybe it’s not optimal to make them singleton methods of Object, a
module would probably be better.


#180

On 6/16/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

On Sat, 17 Jun 2006 removed_email_address@domain.invalid wrote:

Eeek! Please, no “singleton”. Anything but “singleton”.

what’s wrong with singleton? alternatives?

-a

Off the top of my head:

extension &block
inheritance &block
effects &block (in both senses - i.e. this is what it makes happen and
this is what it ‘bequeathes’ to its inheritors)

Regards,
Sean