Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Tuesday 07 February 2006 13:11, Shaun Cutts wrote: By delegation support I mean support for being a proxy for an interface, and delegating its fulfillment to a subobject. Okay, the explanation helped a lot, though I do not like it. But people on the zope.interface list might feel different. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Monday 06 February 2006 11:53, Shaun Cutts wrote: I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Yes, there has been suggestions in this direction before. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MethodSpecification http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SpecificationUnification Obviously this might be a subject for zope.interface. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. I don't understand what you mean. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. Well, it is a matter of overhead. We don't feel that everyone needs zope.schema. See the twisted guys for example. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. If you feel strongly about this, bring it up on the zope.interface mailing list. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) Yep, it is nice for RDB things. But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? You have to ask him and the zope.interface mailing list. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zope.schema: defaults for non-immutables... questions
Stephan, By delegation support I mean support for being a proxy for an interface, and delegating its fulfillment to a subobject. For instance (by example): class ISomeContainer( Interface ): ... class ISoup( Interface ): ... class SomeContainer: implements( ISomeContainer ) class SoupedUpContainer: implements( ISomeContainer, ISoup ) delegateToInstanceAttribute( ISomeContainer, 'theContainer' ) def __init__( self ): self.theContainer = SomeContainer() What delegateToInstanceAttribute does is use __metaclass__ to create member functions in the SoupedUpContainer interface to implement the ISomeContainer interface by calling the functions on getattr( self, 'theContainer' ) delegateToClassAttribute would create classmethod members that did the same, except they delegated to a class attribute. (Note -- these names are more descriptive, but long-winded.) In my experience, it is quite common to want to delegate one interface but not another. Currently, even automating this outside of zope.interface now takes messing around with the advise internals, as a custom metaclass is called before the class interfaces are set up, where here we want to do the delegation afterwards. But some mechanism would be very useful, as proxying code is repetitive and thus boring and easy not to maintain. ... I will work up a proposal on this at some point, and post about it to the zope.interface list (which I had overlooked). I just wanted to explain what I meant in case it caught your fancy. As for the separation of zope.interface and zope.schema, I don't really feel Strongly; I just wanted to know why it was done the way it was done. If zope.interface provided better hooks (e.g. in advise) that would make implementing non-core features elsewhere easier. -Original Message- From: Stephan Richter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 5:15 AM To: zope3-dev@zope.org Cc: Shaun Cutts Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions On Monday 06 February 2006 11:53, Shaun Cutts wrote: I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Yes, there has been suggestions in this direction before. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MethodS pecification http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Specifi cationUnification Obviously this might be a subject for zope.interface. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. I don't understand what you mean. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. Well, it is a matter of overhead. We don't feel that everyone needs zope.schema. See the twisted guys for example. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. If you feel strongly about this, bring it up on the zope.interface mailing list. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) Yep, it is nice for RDB things. But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? You have to ask him and the zope.interface mailing list. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zope.schema: defaults for non-immutables... questions
I'll keep getting Jim's agreement or putting up a proposal in mind. As I start to think of how to extend it, I have some general question about zope.schema. I should note that I am not currently a zope user proper (though I will be soon), but was referred to the zope.interface package via twisted. When I looked at it, and the zope3 book, I immediately thought that type checking of attributes could be useful, and so started using zope.schema. I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? - Shaun -Original Message- From: Stephan Richter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 05, 2006 4:40 PM To: zope3-dev@zope.org Cc: Gary Poster; Shaun Cutts Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions On Sunday 05 February 2006 14:42, Gary Poster wrote: ...as I said, Jim disagreed with this sort of change the last time it was brought up. Okay, I did not know that. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Yeah, I forgot about a proposal. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Tuesday 24 January 2006 12:26, Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) Yes, this is even more apparent with the Datetime object, where you often want to make the default now. A proposal to remedy: if the default is a callable object, it is assumed to be a factory. That is dangerous. What if a value is really a callable. How does this sound? (This would apply to missing_value as well.) I would prefer a new defaultFactory argument, which would be more backward-compatible too. A few further questions: 1) who should be responsible for setting defaults, and how should it be done? I have a base class from which I derive (e.g.) Bar, whose constructor loops through fields of interfaces provided by the instance: for iface in zope.interface.providedBy( self ): for fname, field in zope.schema.getFields( iface ).iteritems(): It checks default missing_value, and sets them. However, if one field shadows another in the interfaces, there is no guarantee that I hit them in the right order. Might it not be good to have a attributesProvidedBy( instance ) in zope.interface that guarantees that it passes back the most derived versions (and resolves consistently when there is no most derived )? Usually we do not enforce defaults like that. Defaults are provided by the constructor arguments. The default value is really only used for the UI. Also, currently, when something doesn't have a definition, and is not required, I check first for default then for missing_value, and use the first I find as a missing value. Is this correct? Yes, I think so. How should default and missing_value interact with each other? What makes most sense to me is: (pseudocode): If not specified: If default defined Use default Else If required Raise error Else If missing value defined Use missing value Else Raise error Finally, a missing missing_value eventually gets None in the current Field constructor. Shouldn't it be left undefined when it wasn't specified? (Same for default.) I think using None as a default for missing_value is ok, so the only thing I would change in your pseudo code is to change the last error raising to: missing_value = None BTW, I am really glad someone is looking at this code. It has not gotten the attention it deserves. Thank you very much! I really hope you will get checkin rights and check in your suggestions! :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Feb 5, 2006, at 12:20 PM, Stephan Richter wrote: On Tuesday 24 January 2006 12:26, Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) Yes, this is even more apparent with the Datetime object, where you often want to make the default now. That's true. It's been raised before...and changes like this have not been approved by Jim. [...] BTW, I am really glad someone is looking at this code. It has not gotten the attention it deserves. Thank you very much! I add my thanks. But... I really hope you will get checkin rights and check in your suggestions! :-) ...as I said, Jim disagreed with this sort of change the last time it was brought up. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: Mutable is a better way to say non-immutable. :-) class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a “Foo” is not immutable this doesn’t make sense. (In my case, I want “a” to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) I've run into this myself. How about: a = Object(schema=IFoo, default_factory=Foo) ? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zope.schema: defaults for non-immutables... questions
Shane, I considered 'default_factory' myself It seems good, but it complicates the logic internally. For one thing, logically, we'd have to also have 'missing_value_default' (unless we decree that missing values have to be not-non-immutable, ah... immutable). A further thought on where to put filling in of defaults code -- this should probably be a separate routine in zope.schema: setDefaults(instance), which would set defaults (and validate? -- or maybe call it setDefaultsAndValidate). - Shaun PS anyone have idea or best practice on how to best through attributes, avoiding shadowed ones? Seems like this is generally useful for introspection of metadata. -Original Message- From: Shane Hathaway [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 12:39 PM To: Shaun Cutts Cc: zope3-dev@zope.org Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: Mutable is a better way to say non-immutable. :-) class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a Foo is not immutable this doesn't make sense. (In my case, I want a to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) I've run into this myself. How about: a = Object(schema=IFoo, default_factory=Foo) ? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
