[Python-Dev] Object customization

[Ken Manheimer]

On Sun, 16 Apr 2000 Vladimir.Marangozov@inrialpes.fr wrote:

> 
> [Skip, on attaching access control rights to function objects]
> 
> > [VM]
> > >...
> > > If you prefer embedded definitions, among other things, you could do:
> > > 
> > > 	__zope_access__ = { 'Spam' : 'public' }
> > > 
> > > 	class Spam:
> > > 	    __zope_access__ = { 'eggs' : 'private',
> > >                                 'eats' : 'public' }
> > > 	    def eggs(self, ...): ...
> > >             def eats(self, ...): ...
> 
> [Greg]
> > This is uglier than attaching the metadata directly to the target that you
> > are describing! If you want to apply metadata to functions, then apply
> > them to the function! Don't shove them off in a separate structure.
> [...]
> In this particular use case, we're discussing access control rights
> which are part of some protection policy.
> A protection policy is a matrix Objects/Rights. It can be impemented
> in 3 ways, depending on the system:
> 1. Attach the Rights to the Objects
> 2. Attach the Objects to the Rights
> 3. Have a separate structure which implements the matrix.
> [...]
> [VM]
> > > or have a completely separate class/structure for access control
> > > (which is what you would do it in C, btw, for existing objects
> > > to which you can't add slots, ex: file descriptors, mem segments, etc).
> 
> Which presents an advantage: the potential to change completely the
> protection policy of the system in future versions of the software,
> because the protection implementation is decoupled from the objects'
> and the rights' implementation.

It may well make sense to have the system *implement* the rights somewhere
else.  (Distributed system, permissions caches in an object system, etc.)  
However it seems to me to make exceeding sense to have the initial
intrinsic settings specified as part of the object!

More generally, it is the ability to associate intrinsic metadata that is
the issue, not the designs of systems that employ the metadata.

Geez.  

And, in the case of functions, it seems to me to be outstandingly
consistent with python's treatment of objects. 

I'm mystified about why you would reject that so adamantly!

That said, i can entirely understand concerns about whether or how to
express references to the metadata from within the function's body.  We
haven't even seen a satisfactory approach to referring to the function,
itself, from within the function.  Maybe it's not even desirable to be
able to do that - that's an interesting question.  (I happen to think it's
a good idea, just requiring a suitable means of expression.) But being
able to associate metadata with functions seems like a good idea, and i've
seen no relevant clues in your "first principles" about why it would be
bad.

Ken
klm@digicool.com



Return-Path: <sc-publicity-return-2-python-dev=python.org@software-carpentry.com>
Delivered-To: python-dev@python.org
Received: from merlin.codesourcery.com (merlin.codesourcery.com [206.168.99.1])
	by dinsdale.python.org (Postfix) with SMTP id 7312F1CD5A
	for <python-dev@python.org>; Sat, 15 Apr 2000 12:50:20 -0400 (EDT)
Received: (qmail 17758 invoked by uid 513); 15 Apr 2000 16:57:54 -0000
Mailing-List: contact sc-publicity-help@software-carpentry.com; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Delivered-To: mailing list sc-publicity@software-carpentry.com
Delivered-To: moderator for sc-publicity@software-carpentry.com
Received: (qmail 16214 invoked from network); 15 Apr 2000 16:19:12 -0000
Date: Sat, 15 Apr 2000 12:11:52 -0400 (EDT)
From: <gvwilson@nevex.com>
To: sc-announce@software-carpentry.com,
	sc-publicity@software-carpentry.com
Message-ID: <Pine.LNX.4.10.10004151146020.17967-100000@akbar.nevex.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Python-Dev] Software Carpentry entries now on-line
Sender: python-dev-admin@python.org
Errors-To: python-dev-admin@python.org
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0beta3
List-Id: Python core developers <python-dev.python.org>

First-round entries in the Software Carpentry design competition are now
available on-line at:

    http://www.software-carpentry.com/entries/index.html

Our thanks to everyone who entered; we look forward to some lively
discussion on the "sc-discuss" list.

Best regards,
Greg Wilson
Software Carpentry Project Coordinator