[1062] in Coldmud discussion meeting

[COLD] Re: frobs

daemon@ATHENA.MIT.EDU (Sat Aug 10 17:30:41 1996 )

From: silovic@srce.hr (Miroslav Silovic)
To: coldstuff@cold.org
Date: Sat, 10 Aug 1996 23:15:34 +0200 (MET DST)

> 
> Solutions:
> 
>   * Prefix frob methods with 'frob_' (or some other such prefix), which 
>     is handled behind the scenes and on-the-fly.  This is _ok_, but it
>     would kill any efficiency with using Frobs.
>   * Create multiple 'scopes' for methods where they do not cross.  I.e.
>     you could have two .name() methods, one for use when it is called
>     from a frob, and one for when it is called from an object.  This could
>     be further extended to private methods as well, although then you
>     would either have to devise a special 'local-call' operator (other
>     than '.') or you would have to add more lookup steps to the current
>     method lookup.
> 
> 

Okay, here was my answer to the problem: Instead of a change in the method
naming (which fubars lookup), I suggested adding 'frob flag to methods.
The flag would act as follows:

	* if method flagged as frob is called like object.method(), it will
	  behave like a normal method. In particular, an attempt to override
	  a !over method will fail (and the parent's method will be called).
	* if method flagged as frob is called like (<object, rep>).method(),
	  it will take priority.

This behaves similarily as different namespaces, except that you can
call frob methods like normal ones (unless they're overriding parents),
you can easily make them recursive, and there is no cruft in the lookup
code (except for overriding, then it would become slightly more complex).

Brandon dislikes this idea, I still don't understand the reasons. Thoughts? :)

	Miro