[Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal

2000-11-30 Thread Jim Fulton

Guido van Rossum wrote:
 
  Is security really a part of an object's interface?  I thought this was more
  of an implementation thing.
 
 Good point.  Certainly in Unix I can have two things implementing the
 same interface (e.g. two named pipes) with different security
 settings (i.e. modes).
 
 However some security stuff can be part of the interface too: e.g. the
 fact that a Foo object has Read, Write and Execute permissions is
 usefully specified as part of its interface.  Whether a particular Foo
 instance has a given permission for a certain user is up to the
 instance.

I think we're talking about a different level of security setting
here.  In unix, you have certain fixed permissions (e.g. read, write,
execute).  The OS maps these permissions onto certain low-level operations
for the few objects it knows about.  This is about mapping permissions
onto objects, rather than deciding what users or groups have 
what permissions on an object.

In Zope, the programmer defines abstract permissions and decides how to map
the abstract permissions to object operations. It is this mapping that
makes sense for interfaces.  

Like Unix, Zope has a separate mechanism for deciding what users/roles
have what permissions on objects. This should not be part of the 
object interface.  These settings are done by users/administrators.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
Technical Director   (888) 344-4332http://www.python.org  
Digital Creationshttp://www.digicool.com   http://www.zope.org

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal

2000-11-28 Thread Guido van Rossum

 I notice you mention post/pre conditions (something that UML obviously talks
 about).  I wonder if we want to do a bit of research on Eiffle and it's
 contractual description.  The only thing I wonder is if some of this is
 actually useful programatically, if that makes sense? It's great info, but
 is it useful at runtime?

In Eiffel (I've never heard of Eiffle :-), pre- and post-conditions
are turned into run-time checks, just like assertions.  There are
separate flags to turn code generation for pre- and post-conditions
off.  This is useful, as follows: while debugging your code, turn both
on.  When you've fully debugged an application, you turn both off.
When you've fully debugged a library module, you create two versions:
one with both turned off, for use in fully debugged applications, and
one with pre-conditions on and post-conditions off, for use by other
code that is still in need of debugging.

I've heard that this works very well, and in Python 3000 (when we have
optional static typing) I would love to add this to Python.  If it's
not feature bloat.

--Guido van Rossum (home page: http://www.python.org/~guido/)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] RE: [Geeks] Re: Interface Meta Data proposal

2000-11-28 Thread Tim Peters

[Christopher Petrilli]
 I notice you mention post/pre conditions (something that UML
 obviously talks about).  I wonder if we want to do a bit of
 research on Eiffle and it's contractual description.  The only
 thing I wonder is if some of this is actually useful
 programatically, if that makes sense? It's great info, but is
 it useful at runtime?

Eiffel takes this all very seriously, and supplies several variants of
assertions that are individually togglable.  Preconditions verify a method
is called according to its docs; postconditions verify a method does what
it's advertised to do; anyone who takes debugging seriously is writing
verification code of that kind anyway, and Eiffel automates it to an
extraordinary degree.

Note that's only the tip of "the contract" part:  inherent in any
contracting scheme is the ability to sub-contract.  A subcontractor cannot
require more, nor deliver less, than the original contract specifies.  So,
in Eiffel, for a subclass S that overrides a base class B's method M, the
preconditions for S.M are magically OR'ed with the preconditions for B.M
(S.M can't require more than B.M, but it may require less), and the
postconditions for S.M are magically AND'ed with the postconditions for B.M
(S.M can't deliver less than B.M, but it may deliver more).

The language guarantees to keep all this stuff straight for you, and the
doc-generation system for Eiffel knows all about it too.  This isn't a
collection of random debugging features in Eiffel:  it's all in support of a
particular formal theory of program design.

if-you-can't-check-a-thing-at-runtime-you-can't-know-whether-
   it's-been-satisfied-ly y'rs  - tim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal

2000-11-28 Thread Cees de Groot

Guido van Rossum [EMAIL PROTECTED] said:
When you've fully debugged an application, you turn both off.
When you've fully debugged a library module, you create two versions:
one with both turned off, for use in fully debugged applications, and
one with pre-conditions on and post-conditions off, for use by other
code that is still in need of debugging.

I've heard that this works very well, and in Python 3000 (when we have
optional static typing) I would love to add this to Python.  If it's
not feature bloat.

It works very well in fully debugged applications. In the 99.99% other
applications, advice is to leave the assertions on during production
time so your app will fail fast when a bug pops up (profiling will
point you to the two assertions that needs to be turned off for 
acceptable performance).

Personally, but I'm talking without too much thinking here, I think
support for assertions in Python should be based on generic support
for metaprogramming - there's more than DBC that could benefit from
that (aspect-oriented programming, etcetera).


-- 
Cees de Groot   http://www.cdegroot.com [EMAIL PROTECTED]
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )