Should top have any methods defined on it (eg __send__)?

[sampersand]

Exactly as the title sounds: Should the top type have any methods defined on it? Currently, it does not.

While you can technically undef/redefine some of the more critical methods (i.e. object_id, __send__, and initialize, but interestingly not __id__) in Ruby, you get a stern warning:

$  ruby -e 'class F; undef __send__ end'  
-e:1: warning: undefining `__send__' may cause serious problems

If we want to keep top a pristine "absolutely nothing guaranteed" type, then we may also want to somehow consider denoting that these methods are available on nearly all objects.

I don't feel particularly strongly either way.

[ParadoxV5]

Let’s get it straight: Why differentiate BasicObject (an ancestor class of all classes) and top (the ancestor type of all classes and interfaces)? Is there an arcane exploit capable of creating [P.S fully-functional] non-BasicObject entities via C hacking or some other black magic?

[ParadoxV5]

If we want to keep top a pristine "absolutely nothing guaranteed" type, then we may also want to somehow consider denoting that these methods are available on nearly all objects.

That’d be using BasicObject instead of top.