[Zope-dev] Re: [Geeks] Interface Meta Data proposal
Is security really a part of an object's interface? I thought this was more of an implementation thing. - 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] Interface Meta Data proposal
On 11/28/00 4:05 PM, "Michel Pelletier" [EMAIL PROTECTED] wrote:
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
Without these things being supported more in the core language, it seems
quite awkward. Being able to do the followng is nice:
class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"
class LockToken:
__implements__ = ILocktoken,
...
The following would (will?) be better:
interface ILockToken:
def frame(...):
class LockToken implements(ILockToken):
...
But I'm not sure how one would go about setting your meta-data in a way that
is at all natural to Python. I think that exceptions that a method
must\should raise *should* be part of a signature\contract. This is one of
the really cool things about Java. If you use a method, 'readFile' that
says it raises IOError, you *HAVE* to catch that exception (I believe in
order to compile). But it looks like what you're really wanting is to use
interfaces for documentation purposes, not for contract purposes. Not for
interfaces at this level of the language.
I'm guessing along your proposal, to state that a method raises ValueError
or Attribute I'd have to do the following?:
class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"
frame.setMetaData('exceptions', (ValueError, AttributeError))
...
Meta Data is a deadly term. Be careful with it.
Anyways, I doubt we want to invent our own IDL (no!) or reinvent Eiffel
(specifying pre and post conditions are only truely useful if they're
enforced, and without this enforcement in the core language I imagine that
could be expensive. They're a good thing for large systems, but Python
doesn't support them automatically), so it seems that this information seems
to be best put in the documentation (since doc strings in an Interface don't
also mean "Publish Me!", they can be used to document!).
Interfaces are contracts and pretty darn good ways of specifying parts of
the system, but don't confuse them with headers in C\C++\Objective C.
'IObjectManager' is a critical interface for Zope (so instead of having
attributes like 'isPrincpiaFolderish', we can ask
'IObjectManager.implementedBy(fooObject)'. Folder, on the other hand, is an
important class in Zope, but is primarily an amalgam of classes implementing
important Interfaces (ICopyable, IPropertyManager). It's unlikely that
we'll really have a need for a Folder Interface, because what's important
about Folder's is that they implement ObjectManager behaviors and
CopySupport behaviors.
To bring Java back into play here for a moment, a simple example is the
interface 'Cloneable'. By implementing 'Cloneable', well then.. when it's
time to clone, you can be cloned. If you don't say you implement
'Cloneable', an exception gets raised (even if you implement the proper
method). This is similar to how we sniff things today, but we just do
things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):'
I get the feeling sometimes that what you want with interfaces is actually a
bit closer to what Objective C does with the word Interface. And that is
that in Foo.h, you have the interface for class Foo:
@interface Foo {
...
And in Foo.m, you have the implementation:
@implementation Foo {
...
These interfaces are header files, and they're damn nice to use for
documentation since the specification of the class is separate from the
implementation. But they don't imply contracts in the way that Java's use
of the word Interface does. (Some implementations of Objective C call those
things Protocols).
Both needs are valid, but I think we'll benefit most from the first
(contracts). In order to make those work, we probably shouldn't make them
too foreign to specify, or the incentives to write them go way down (as is
evidenced by the amount of doc strings that go """ """ or "XXX: Fill in
later", getting developers to fill in too much 'meta data' is hard).
But if we can get some of the information in your proposal more integrated
with the language, I think it would be beneficial.
Jeffrey P Shell, [EMAIL PROTECTED]
http://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] Interface Meta Data proposal
Chris McDonough wrote: Is security really a part of an object's interface? Maybe. Are examples? Also maybe. It's documentation, so specific systems that use interfaces may want to be able to extend the kinds of information they can associate with interface elements. I thought this was more of an implementation thing. These are good questions, I think these also have a great effect on the Zope 3 story. BTW, the whole idea of extensible meta-data on an interface element came from reading the Zope 3 story so far, and seeing the examples that include security assertions in an interface. Amos and I discussed it a bit and that's where the proposal came from. -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 )
Re: [Zope-dev] Re: [Geeks] Interface Meta Data proposal
Jeffrey P Shell [EMAIL PROTECTED] said: But I'm not sure how one would go about setting your meta-data in a way that is at all natural to Python. I think that exceptions that a method must\should raise *should* be part of a signature\contract. This is one of the really cool things about Java. If you use a method, 'readFile' that says it raises IOError, you *HAVE* to catch that exception (I believe in order to compile). It's so cool, it really chills your productivity. The moment that Python starts doing that, I'll drop the language like a hot iron. 'Nuff about thermodynamics. Making exceptions statically checked is probably the worst misfeature of Java. The idea is nice, in that it forces you to deal with exceptions, but in reality it gets in the way too soon - when you're still exploring, refactoring, stuff like that you should be able to turn the damn things off. I've got five years of full-time Java programming behind me, so I know what I'm talking about. But it looks like what you're really wanting is to use interfaces for documentation purposes, not for contract purposes. Not for interfaces at this level of the language. Useful documentation, especially contracts, can be useful programmatically so stuff like that should at least be setup so that it is possible to move it into the language. A bit like the @pre and @post tags in Javadoc comments - they're always nice to have as documentation, but when you run iContract over them, they are activated and start checking your code's behavior. If you don't say you implement 'Cloneable', an exception gets raised (even if you implement the proper method). Another wart in Java that is nice in theory, but sits in your way in practice. I greatly prefer the Smalltalk "protocols" approach, where implementing an interface is accomplished by implementing the right methods period. The funny thing is, hardly any Smalltalk code ever checks for the interface: the (correct) assumption is that if you hand something over to some other thing that says it wants to iterate over whatever you handed over, you'd better be sure that the thing behaves at least enough like a collection so that it can be iterated over. That's the caller's responsibility (a sort of implicit precondition), and if the caller sends over something else, you get a DoesNotUnderstand exception. Very often I have longed in Java for the possibility of an object to implement a subset of behavior of another object, but that's not possible. For example, if you have a bunch of field labels you stuff in a collection just to be able to do getText()/setText() on them (say for internationalization). Now, I want to add menu labels to that collection, they also have getText()/setText() so they would be good citizens in that collection. Java does not allow that, unless I'm prepared to jump through instanceof/type casting hoops (which is only possible if I'm the one actually calling getText()/setText()). This is similar to how we sniff things today, but we just do things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):' The usual answer of an OO guru here is that if statements are considered harmful, and that if statements that check object types are considered very harmful. The modern variant is "these are strong refactoring smells". -- 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 )
