Re: [Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
Guido van Rossum wrote: > > 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. Note that UnitTests are there for Python now, and they can accomplish something similar. Advantage is that the tests already separate from the code so you don't have to turn them off, disadvantage is that the tests are too far from the code to encourage their use, perhaps. A good set of unit tests that are run often during development definitely feels like a good safety net. Regards, Martijn ___ 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
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 )
Re: [Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
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 )
[Zope-dev] RE: [Geeks] Re: Interface Meta Data proposal
[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 )
[Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
Chris McDonough wrote: > > Is security really a part of an object's interface? I thought this was more > of an implementation thing. When refactoring the PTK it became apparent that supplying security assertions on the interface rather than the implementation can be very useful. In fact, an interesting pattern emerged: "view" objects needed no security assertions as long as the "model" objects had all the necessary assertions. I'm not sure if there is any basis for this idea in current OO methodology, but I really think the concept has merit. It certainly clarifies Zope security IMHO. Shane > - Original Message - > From: "Michel Pelletier" <[EMAIL PROTECTED]> > To: "Geeks Mailing List" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, November 28, 2000 4:05 PM > Subject: [Geeks] Interface Meta Data proposal > > > > > I've added a sub-proposal to the Interface proposal for describing > > additional meta-data with Interface objects: > > > > http://www.zope.org/Wikis/Interfaces/ExtesableMetaData > > > > Please comment about this interesting possibility. > > > > -Michel > > ___ 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
> 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 )
