|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.
In message “Re: Why the lack of mixing-in support for Class methods?”
on Fri, 16 Jun 2006 02:01:53 +0900, [email protected] 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.
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).
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.
| 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”.
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.
In message “Re: Why the lack of mixing-in support for Class methods?”
on Fri, 16 Jun 2006 18:56:23 +0900, [email protected] 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?
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.
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.
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’.
|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:
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)