[1063] in Coldmud discussion meeting
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.
-Brandon