[Zope-dev] Re: PROBLEM(100) Init Ambiguous name

[Shane Hathaway]

On Sat, 28 Jul 2001, Steve Alexander wrote:

> Chris Withers wrote:
> > From: "Chris McDonough" <chrism@zope.com>
> >
> >>If someone summarizes the distinctions made in this email, I can put it
> >>in the ZDG.
> >>
> >
> > 1. You can't protect a method with more than one permission.
> >
> > 2. If a method aliases another method:
> >
> >    e.g. manage_main = manage_editForm
> >
> >    ...then they both HAVE to be protected by the same permission.
>
> And what about the _setName stuff?
>
> How about:
>
>    When you have two attributes that resolve to the same method,
>    and that method is protected by a permission, you need to
>    call _setName on the method. The argument to _setName is
>    the name of the attribute that you used in the permission
>    declaration.
>
> I still don't really understand why this is needed... I guess I'll need
> to do some digging in the latest security code.

Again, this problem has always existed.  I was working on a Script
(Python) recently and tried to set it up so that a restricted user could
edit scripts.  Strangely, no security setting (including granting *all*
permissions to the user's role) would allow access to the script editing
form.

I dug further and realized that even though there was a
declarePermission() for the edit method, the declaration was being ignored
because Zope thought the method was supposed to have a different name.
Zope had guessed the name of the method incorrectly.  It had assigned
security to it in such a way that only users with the "Manager" role,
regardless of permissions, could see it.

The bug is not easily reproduced because it actually depends on the order
of items retrieved from a dict, which is indeterminate.  But I assure you,
it exists and has probably bitten a lot of us at some time or another.  In
fact, when I first installed the warning a dozen modules of Zope itself
reported the warning.

Hopefully a future version of Python will let us solve this in a more
elegant way.  There would need to be some way to distinguish aliases from
original names of DTMLMethods.  The "def" statement, for example,
automatically includes the canonical name of a function in the produced
function object, so there's no ambiguity.  Maybe something like:

def <DTMLMethod> manage_editForm('editForm', globals())

... or ...

def as DTMLMethod manage_editForm('editForm', globals())

... or just ...

DTMLMethod manage_editForm('editForm', globals())

... using the conjunction of two identifiers as a signal to call the first
identifier with the second identifier as the first argument and anything
in parentheses as the remaining arguments, then storing the results of the
call in the current scope using the second identifier.

Yuk, yuk, yuk :-)

You could then do this:

Integer a(1)

Then you could have a modified syntax that lets you use the equal sign
instead of parentheses.

Integer a = 1

This-is-why-I'm-not-a-language-designer-ly y'rs, Shane