[1063] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next last

Re: [COLD] Re: frobs

daemon@ATHENA.MIT.EDU (Sat Aug 10 18:15:30 1996 )

Date: Sat, 10 Aug 1996 16:04:19 -0600 (MDT)
From: Brandon Gillespie <brandon@tombstone.sunrem.com>
To: Miroslav Silovic <silovic@srce.hr>
cc: coldstuff@cold.org
In-Reply-To: <199608102115.XAA24977@regoc.srce.hr>

> > 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? :)

It isnt a complete solution.  With this idea you still cannot have a frob
method and an object method on the _SAME_ object, without having it
hacked.  Furthermore you have to add special cases to disallowing
overrides, and I really dont like that idea as you could unintentionally
introduce security holes--not to mention that disallowing an override is 
just that, it DISALLOWS overriding.