RE: [Zope-dev] Mail and zope

2000-11-28 Thread Matt Hamilton

 originated from but most e-mail clients discard custom headers but preserve
 a 'In-Reply-To' header with the original message-id.

Don't count on it! :)  I spent quite some time working on a full-text
mailing list search/archive system and one of the things I wanted to do
was preserve thread informtion.  However it was surprising the number of
MUAs that did not generate a In-Reply-To header.  Mostly it was Microsoft
Mail Client and quite a few similar internal mail systems with internet
gateways.  Also beware that many mailers use the NNTP standard of
References: instead of in-reply-to.  I would suggest using the Subject
line instead and generate some sort of ticket number and store it in the
subject line, and put a header in the message body instructing the user to
not alter the subject. 

-Matt

-- 
Matt Hamilton[EMAIL PROTECTED]
Netsight Internet Solutions, Ltd. Business Vision on the Internet
http://www.netsight.co.uk  +44 (0)117 9090901
Web Hosting  |  Web Design  |  Domain Names  |  Colocation  |  DB Integration



___
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] RFC: Python/Zope Interfaces: ZCatalog

2000-11-28 Thread Chris Withers

Ken Manheimer wrote:
 
 I'm not expert on eiffel or even interfaces, but my understanding having
 interface "specification very near to the implementation" is misleading,
 at best.  The key thing is that there may be many implementations, all of
 which should be written to the same implementation - so you do not want

Should that be 'same interface'?

 the interface specification tied to any one of them.

This is a very good point!

I'd be really interested in making something that supported the Catalog
'interface' but actually used the new MySQL full-text searching stuff to
do the indexing/searching.

However, until Catalog has a defined _interface_, I'm not even going to
think about starting :-S

Anyone know when that's likely to happen?

cheers,

Chris

___
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] fixing security problems HOW?

2000-11-28 Thread Robin Becker

How can I find out exactly what is causing my security permissioning to
fail.

I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I
know that I'm failing on

UnauthorizedYou are not authorized to access this resource.
URL='http://192.168.0.4:7080/live/index_html' No Authorization header
found.

I am an anonymous user. Even when I make /live have the same permissions
as the manager I can't make it work. index_html is a dtml method of the
class of which live is an instance.

How can I figure out what is blocking the anonymous access.
-- 
Robin Becker

___
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] CVS down?

2000-11-28 Thread Robin Becker

C:\Python\devel\Zopecvs -z9 upd -A -P -d
CVS.EXE [update aborted]: connect to zope.org:2401 failed: Connection
refused


Am I pointing at the wrong server or something?
-- 
Robin Becker

___
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] RFC: Python/Zope Interfaces

2000-11-28 Thread Jim Fulton

Lalo Martins wrote:
 
 On Fri, Nov 24, 2000 at 08:11:48AM -0800, Michel Pelletier wrote:
  Python Interface Proposal
 
I have been working on a proposal for enhancing the existing interface
documentation in Zope.  The Wiki for this project can be found here:
 
 As far as what's written on the proposal is concerned, I like it.
 
 Technically, I have one objection to the interface
 documentation system:
 
 Why must I create a new "dummy" Python file?

I don't think you do need to create a dummy Python
file. You *do* need to define interfaces, in whatever files
you choose. 

 Why can't the
 system extract the data from the Python source itself?

Because the (class) source is about implementation, not
interface.  A class often implements multiple interfacs, 
and multiple classes often implement the same interface.
For that reason, it makes sense to define interfaces and
classes independently.

 Duplicating work is never good, and there are even people who
 like literate programming :-)

There is no duplications. Interfaces and classes are two different
kinds of beasts.

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] RFC: Python/Zope Interfaces

2000-11-28 Thread Jim Fulton

Michel Pelletier wrote:
 
 Lalo Martins wrote:
 
  On Fri, Nov 24, 2000 at 08:11:48AM -0800, Michel Pelletier wrote:
   Python Interface Proposal
  
 I have been working on a proposal for enhancing the existing interface
 documentation in Zope.  The Wiki for this project can be found here:
 
  As far as what's written on the proposal is concerned, I like it.
 
  Technically, I have one objection to the interface
  documentation system:
 
  Why must I create a new "dummy" Python file? Why can't the
  system extract the data from the Python source itself?
 
 You can, of course, because you can just pass the Interface costructor a
 class.

This is, in my strongly-held opinion, a bad idea.  Most classes
implement multiple interfaces, and trying to suck interfaces out of
a class definition will tend to generate sloppy interfacesl.

I added a comment on this to your Wiki page. :)

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] fixing security problems HOW?

2000-11-28 Thread Shane Hathaway

Robin Becker wrote:
 
 How can I find out exactly what is causing my security permissioning to
 fail.
 
 I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I
 know that I'm failing on
 
 UnauthorizedYou are not authorized to access this resource.
 URL='http://192.168.0.4:7080/live/index_html' No Authorization header
 found.
 
 I am an anonymous user. Even when I make /live have the same permissions
 as the manager I can't make it work. index_html is a dtml method of the
 class of which live is an instance.
 
 How can I figure out what is blocking the anonymous access.

1) Use the -D option to start Zope in debugging mode.

2) Install ZDebug.

3) Add a user with the essential permissions and see if *that* user can
get access.

Shane

___
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] RFC: Python/Zope Interfaces

2000-11-28 Thread Jim Fulton

Dieter Maurer wrote:
 
 Michel Pelletier writes:
   Also, defining the interface seperately keep the two things apart,
   impementation and interface, and doesn't allow you to sneak in a new
   method unless you also sneak it into the interface, thus making a
   stronger "contract" with the user.
 I am a bit astonished by this statement:
 
   I know the "design by contract" concept from Bertrand Meyer,
   the Eiffel developper.
 
   In Eiffel, essential parts of the contract, among others
   method prototype, pre- and post-conditions as well as invariants
   are build directly into the language.
   A documentation tool extracts these parts
   from the source to generate the interface, for people
   that are only interested in how to use the class/method.
 
   Programms can be executed in a way, that the various
   (executable) contract parts can be checked at runtime.
   *THIS* provides for quite a strong contract.
 
 I cannot see, why the separation of interface and implementation
 should make the contract stronger.

The interface *is* the contract. If someone builds a house
for me, I don't want the house to *be* the contract. I want the
house to adhere to the contract.  Interface/contract and implementation
are two qualitatively different things.

 I do see, however, that it
 makes it more likely to be broken by the implementation.

I don't think it makes it more or less likely. Of course, 
if the "interface" is always derived from the implemenation
then the two will be consistent, but this is not 
terribly useful.

 It is a very good thing to have the specification very near
 to the implementation -- as a permanent guide to the
 implementor.

Firtunately, modern displays allow multiple side-by-side
windows. ;)

 It is even better, when big parts of the
 specification becomes part of the executable code
 (as is the case for Eiffel's pre- and post-conditions).
 
 If you want to prevent your implementors to change the
 interface specification, generate the interface for the
 implementation and compare against your master copy.
 
 In my view, it is better to have a somewhat "weaker" contract
 that is met by the partners than a "stronger" contract that
 is violated.

We disagree then. A weak interface that is satisfied by definition
is nearly useless to me.

 Or, to say it differently, it is more essential
 the a system's documentation describes faithfully what is
 rather than what should be (but is not).

I disagree alot. I'd rather have clear documentation of intended 
behavior, rather than have the documentation change based on 
implementation decisions.

Note also that most classes implement multiple interfaces.
Generating interfaces from classes trends to yield bloated
non-cohesive interfaces.

Similarly, most interesting interfaces are implemented by multiple
classes, so nearness to implementation is not really meaningful.

Please note that these points were argued extensively on the Python
types-sig a couple of years ago.

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] objectValues performance

2000-11-28 Thread Casey Duncan

Brett Carter wrote:

 I have a folder with greater than 5000 ZClass instances in it.  It
 takes  5mins to do an objectValues for every object in the folder -
 is there a higher perfomance call I could make?
 -Brett

Standard folder performance degrades pretty quickly once you get
a lot of objects in it. There are two solutions to this:

Subdivide your objects into multiple folders.
Use a BTreeFolder which should be much faster.

You can download the BTreeFolder product
here: http://www.zope.org/Members/hathawsh/BTreeFolder/

hth,
Casey Duncan






___
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] UML reverse engineering on ZClasses - I need somehelp

2000-11-28 Thread Joachim Schmitz



On Tue, 28 Nov 2000, zope wrote:

 Hi!
 
 I am currently developing a tool for reverse engineering 
 ZClasses into UML using ObjectDomain and JPython.
 
 this tool connects directly to a Zope instance and queries
 the ZClass entities, methods and inheritance relations by 
 calling a set of utility methods that I implemented as External methods.
 
 it works fine when reverse engineering ZClasses, their methods and inheritance 
relations.
 
 you can check out a sample result where I reversed a part of Maik Roeder's ZDP tools 
under 
 http://zwork.bluedynamics.com/Tests/zdp/index.html
 
 If there is interest and time I'll document the reverse engineering tool and publish 
it on zope.org
 

this is absolutly fantastic, great job Phil.
If reverse engeneering is possible, also ZClass generation should be possible,
or even better generate a python-product.

I am very much interested in your work.



Mit freundlichen Grüßen

Joachim Schmitz  

  
AixtraWare, Ing. Büro für Internetanwendungen
Hüsgenstr. 33a, D-52457 Aldenhoven  
Telefon: +49-2464-8851, FAX: +49-2464-905163


___
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] CVS down?

2000-11-28 Thread Robin Becker

In article [EMAIL PROTECTED]
m, Ken Manheimer [EMAIL PROTECTED] writes
On Tue, 28 Nov 2000, Robin Becker wrote:

 C:\Python\devel\Zopecvs -z9 upd -A -P -d
 CVS.EXE [update aborted]: connect to zope.org:2401 failed: Connection
 refused
 
 
 Am I pointing at the wrong server or something?

OK that works for me. I had to use cvs_chroot.py, but that seemed to go
OK.
-- 
Robin Becker

___
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] UML reverse engineering on ZClasses - I need somehelp

2000-11-28 Thread Maik Röder

Hi Joachim !

Joachim Schmitz wrote:
  I am currently developing a tool for reverse engineering
  ZClasses into UML using ObjectDomain and JPython.
 
  this tool connects directly to a Zope instance and queries
  the ZClass entities, methods and inheritance relations by
  calling a set of utility methods that I implemented as External methods.
 
  it works fine when reverse engineering ZClasses, their methods and inheritance 
relations.
 
  you can check out a sample result where I reversed a part of Maik Roeder's ZDP 
tools under
  http://zwork.bluedynamics.com/Tests/zdp/index.html
 
  If there is interest and time I'll document the reverse engineering tool and 
publish it on zope.org
 
 
 this is absolutly fantastic, great job Phil.
 If reverse engeneering is possible, also ZClass generation should be possible,
 or even better generate a python-product.

Generating ZClasses out of a model description is what I wanted to do
for a long
time, but I couldn't find someone to fund this. Generating a Python
product is
something that Eric Enge has done with his mkzproduct.
 
I haven't been using "SubObjects" in my ZDP-Tools, so Aggregation is
nowhere
defined, except implicitely.

Best regards,

Maik Röder

___
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] objectValues performance

2000-11-28 Thread Andy McKay

Id recommend all the above but just for reference "objectIds" is faster than
"objectValues".
--
  Andy McKay, Developer.
  ActiveState.

- Original Message -
From: "Casey Duncan" [EMAIL PROTECTED]
To: "Brett Carter" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 28, 2000 7:58 AM
Subject: Re: [Zope-dev] objectValues performance


 Brett Carter wrote:

  I have a folder with greater than 5000 ZClass instances in it.  It
  takes  5mins to do an objectValues for every object in the folder -
  is there a higher perfomance call I could make?
  -Brett

 Standard folder performance degrades pretty quickly once you get
 a lot of objects in it. There are two solutions to this:

 Subdivide your objects into multiple folders.
 Use a BTreeFolder which should be much faster.

 You can download the BTreeFolder product
 here: http://www.zope.org/Members/hathawsh/BTreeFolder/

 hth,
 Casey Duncan






 ___
 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 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] RFC: Python/Zope Interfaces: ZCatalog

2000-11-28 Thread Michel Pelletier

Chris Withers wrote:
 
 Ken Manheimer wrote:
 
  I'm not expert on eiffel or even interfaces, but my understanding having
  interface "specification very near to the implementation" is misleading,
  at best.  The key thing is that there may be many implementations, all of
  which should be written to the same implementation - so you do not want
 
 Should that be 'same interface'?
 
  the interface specification tied to any one of them.
 
 This is a very good point!
 
 I'd be really interested in making something that supported the Catalog
 'interface' but actually used the new MySQL full-text searching stuff to
 do the indexing/searching.
 
 However, until Catalog has a defined _interface_, I'm not even going to
 think about starting :-S
 
 Anyone know when that's likely to happen?

A couple of years ago. (hehe - sorry, had to).  The Z Search Interface
is well defined (not well documented) and the Catalog is not the only
object that implements it, so do ZSQL Methods and Z Network Adapters
(which you've probably never heard of, they're buried in the CVS
somewhere...).  The 'Z Search Inteface' object is one tool in particular
that uses it, perhaps you can in imply the interface from that since it
is not documented.

-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] objectValues performance

2000-11-28 Thread Brett Carter


Ok, I'll bite.  Why doesn't the standard folder scale?  Seems like a
design flaw to me - why doesn't the default folder use catalogs or BTrees?
-Brett

 "Casey" == Casey Duncan [EMAIL PROTECTED] writes:

Casey Brett Carter wrote:
 I have a folder with greater than 5000 ZClass instances in it.  It
 takes  5mins to do an objectValues for every object in the folder -
 is there a higher perfomance call I could make?
 -Brett

Casey Standard folder performance degrades pretty quickly once you get
Casey a lot of objects in it. There are two solutions to this:

Casey Subdivide your objects into multiple folders.
Casey Use a BTreeFolder which should be much faster.

Casey You can download the BTreeFolder product
Casey here: http://www.zope.org/Members/hathawsh/BTreeFolder/

Casey hth,
Casey Casey Duncan






___
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] objectValues performance

2000-11-28 Thread Michel Pelletier

Brett Carter wrote:
 
 Ok, I'll bite.  Why doesn't the standard folder scale?  Seems like a
 design flaw to me - why doesn't the default folder use catalogs or BTrees?
 -Brett

Because massive scale is not a requirment of folders, they are meant to
organize content for humans, not to be large-collection containers.  A
folder with 5000 elements is not very useful to a human.

On a similar note, create 5000 files in a linux directory on a ext2
(standard) filesystem and then type 'ls'.  You'll notice they don't
scale very well either, which is why there are filesystems like
ReiserFS.

-Michel
 
  "Casey" == Casey Duncan [EMAIL PROTECTED] writes:
 
 Casey Brett Carter wrote:
  I have a folder with greater than 5000 ZClass instances in it.  It
  takes  5mins to do an objectValues for every object in the folder -
  is there a higher perfomance call I could make?
  -Brett
 
 Casey Standard folder performance degrades pretty quickly once you get
 Casey a lot of objects in it. There are two solutions to this:
 
 Casey Subdivide your objects into multiple folders.
 Casey Use a BTreeFolder which should be much faster.
 
 Casey You can download the BTreeFolder product
 Casey here: http://www.zope.org/Members/hathawsh/BTreeFolder/
 
 Casey hth,
 Casey Casey Duncan
 
 ___
 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 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: PathHandler: bug, readme.txt

2000-11-28 Thread Phil Harris

To my mind it's the browser.

This is a simple trick I use when egating the caching in IE for instance.

Stick a space on the end of the url and IE thinks it's a new one but blindly
strips them before getting the same refreshed page.

This works with any server and any page on that server btw.

Phil

- Original Message -
From: "Chris Withers" [EMAIL PROTECTED]
To: "Willem Broekema" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, November 28, 2000 1:57 PM
Subject: [Zope-dev] Re: PathHandler: bug, readme.txt


| Willem and Zope-Dev'ers,
|
| Willem Broekema wrote:
| 
|  Hi Chris,
| 
|  PathHandler is a nice and really useful product!
|
| Thanks :-)
|
|  A question though: is it on purpose that it ignores spaces at the end of
|  the url, as in:
| 
|  http://site/ph/%20d%20  -- path_to_handle == [' d'] instead of [' d ']
| 
|  (%20 is the escape code for a space)
| 
|  Although it's really a minor minor thing, letting the user decide how to
|  deal with spaces might be a tiny improvement.
|
| Well, it's not PathHandler that's stripping spaces, so either Zope is,
| or maybe even your browser is.
| Anyone got any ideas?
|
| That said, handling of spaces and %20's in URLs isn't very well defined
| anyway, so I would avoid it if you can...
|
|  And in the README.txt file, please replace
|  dtml-var path_to_handle with lt;dtml-var path_to_handlegt; so it
|  won't be ignored in the browsers.
|
| Well, I think this is a bug with Zope. README.TXT is a text file,
| formatted so it will render nicely in structured text.
| It does this in the management interface for the PathHandler product,
| but the  and  aren't quoted properly.
| I wonder why that is?
|
| Hmmm... anyone know what happened to StructuredTextNG?
|
| Anyway, README.TXT is primarily designed as a text file, and
| lt;dtml-var path_to_handlegt; isn't very easy to read when viewing a
| text file ;-)
| So, I guess someone needs to fix Zope for at least one and maybe both of
| your problems to go away.
|
| Any ideas?
|
| cheers,
|
| Chris
|
| ___
| 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 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] Interface Meta Data proposal

2000-11-28 Thread Michel Pelletier


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 )




Re: [Zope-dev] objectValues performance

2000-11-28 Thread Casey Duncan

Brett Carter wrote:

 Ok, I'll bite.  Why doesn't the standard folder scale?  Seems like a
 design flaw to me - why doesn't the default folder use catalogs or BTrees?
 -Brett

AFAIK a standard folder uses a linear search when you request an object from it
(ala Python dictionaries, someone please correct me if I'm wrong). This works
great except that the search time grows linearly (by n) as you add objects. The
BTreeFolder as the name implies creates a binary tree of the objects where the
search time grows by only log n. For small folders the search time difference
is minimal to non-existant, but as n increases the BTreeFolder search time
increases minimally. B-trees are fairly complex entities to manage and for the
vast majority of folders are total overkill. That is why standard folders work
the way they do, the implementation is simple and efficient for 99.9% of
applications. Your case is fairly atypical of most Zope folders.

Perhaps a future implementation of Zope folders could automatically use a
b-tree after a certain threshold is reached, for now you must explicitly select
them.

Andy's idea of using objectIds instead of objectValues is also a good one which
will save significant amounts of memory. You can always access each object
individually via id if you need to. Using a  ZCatalog could also help in this
because you can query the objects without loading them into memory and the
returned result does not load the objects themselves, only the meta-data and
only once a result item is explicitly accessed (By using so-called lazy
sequences). However the catalog will not speed up your actual object access
time unless you divide them up amongst several folders or use a BTreeFolder.
The latter being a simpler solution from a design standpoint.

Good luck!

Casey Duncan


___
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

2000-11-28 Thread Chris McDonough

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] 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] Interface Meta Data proposal

2000-11-28 Thread Jeffrey P Shell

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

2000-11-28 Thread Michel Pelletier

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] objectValues performance

2000-11-28 Thread Brett Carter


 "Michel" == Michel Pelletier [EMAIL PROTECTED] writes:

Michel Because massive scale is not a requirment of folders, they
Michel are meant to organize content for humans, not to be
Michel large-collection containers.  A folder with 5000 elements
Michel is not very useful to a human.

Michel On a similar note, create 5000 files in a linux directory on a ext2
Michel (standard) filesystem and then type 'ls'.  You'll notice they don't
Michel scale very well either, which is why there are filesystems like
Michel ReiserFS.

Michel -Michel

Point taken, but in Zope where data and logic reside in the same place
(ZODB) shouldn't we have some sort of effcient storage for large amounts
of data?  What happens when a site gets three or four thousand users?
That won't fit well in an UserFolder.  
-Brett

[...]


___
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] fixing security problems HOW?

2000-11-28 Thread Dieter Maurer

Robin Becker writes:
  How can I find out exactly what is causing my security permissioning to
  fail.
  
  I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I
  know that I'm failing on
  
  UnauthorizedYou are not authorized to access this resource.
  URL='http://192.168.0.4:7080/live/index_html' No Authorization header
  found.
  
  I am an anonymous user. Even when I make /live have the same permissions
  as the manager I can't make it work. index_html is a dtml method of the
  class of which live is an instance.
  
  How can I figure out what is blocking the anonymous access.
The URL traversal in "ZPublisher.BaseRequest.traverse"
led to a "roles" assignment with a non-"None" value.
This triggers authentication checking.
Annonymous did not have one of the necessary roles.

I would probably check, what "roles" are determined during
traversal.

Apparently, your "live" is a Z instance.
It is quite easy to forget the ZClass permission mapping
(or get it wrong). This may lead to strange permission
problems.


Dieter

___
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] RFC: Python/Zope Interfaces

2000-11-28 Thread Dieter Maurer

Michel Pelletier writes:
  Dieter Maurer wrote:
   Michel Pelletier writes:
 Also, defining the interface seperately keep the two things apart,
 impementation and interface, and doesn't allow you to sneak in a new
 method unless you also sneak it into the interface, thus making a
 stronger "contract" with the user.
   I am a bit astonished by this statement:
   
  
  I'm not sure if you are making these statement because you
  disagree with the current proposal or because you disagree with what I
  said above.
I disagree with the "separating implementation and interface
makes for a stronger contract".

Separation by itself does not make the contract stronger.


Dieter

___
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] RFC: Python/Zope Interfaces

2000-11-28 Thread Dieter Maurer

Ken Manheimer writes:
   Dieter Maurer wrote:
It is a very good thing to have the specification very near
to the implementation -- as a permanent guide to the
implementor. It is even better, when big parts of the
specification becomes part of the executable code
(as is the case for Eiffel's pre- and post-conditions).
  
  I'm not expert on eiffel or even interfaces, but my understanding having
  interface "specification very near to the implementation" is misleading,
  at best.  The key thing is that there may be many implementations, all of
  which should be written to the same implementation - so you do not want
  the interface specification tied to any one of them.
What about *ALL* of them.

Source documentation is essential for high quality software.
A major part of the documentation is what each programming
entity is obliged to do by contract.
Therefore, I would like this information to be near the
implementation.



Dieter

___
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] RFC: Python/Zope Interfaces

2000-11-28 Thread Dieter Maurer

Jim Fulton writes:
  Dieter Maurer wrote:
   I cannot see, why the separation of interface and implementation
   should make the contract stronger.
  
  The interface *is* the contract. If someone builds a house
  for me, I don't want the house to *be* the contract. I want the
  house to adhere to the contract.  Interface/contract and implementation
  are two qualitatively different things.
But this does not imply, that the contract becomes stronger,
when interface and implementation are separated.
Packaging issues do not change the contract.

I see however, that you usually will (should) start with a specification
(the interface is part of it) and then provide an implementation
(or more than one) for it.

   In my view, it is better to have a somewhat "weaker" contract
   that is met by the partners than a "stronger" contract that
   is violated.
  
  We disagree then. A weak interface that is satisfied by definition
  is nearly useless to me.
If an implementation has nothing to do with its specification,
then either the implementation or its specification is useless,
at least in relation to one another.

But, you note, that I did not speak about "a weak interface that
is satisfied by definition" but about a "somewhat weaker
contract that is met by the partners compared to a somewhat
stronger contract but violated contract".


   Or, to say it differently, it is more essential
   the a system's documentation describes faithfully what is
   rather than what should be (but is not).
  
  I disagree alot. I'd rather have clear documentation of intended 
  behavior, rather than have the documentation change based on 
  implementation decisions.
If the implementation decisions are essential: e.g.
linear versus logarithmic time complexity, I would like
to have that stated in the documentation.


  Note also that most classes implement multiple interfaces.
  Generating interfaces from classes trends to yield bloated
  non-cohesive interfaces.
I may agree with this.
Though some configuration for the generation process may help
to reduce the danger.

  Similarly, most interesting interfaces are implemented by multiple
  classes, so nearness to implementation is not really meaningful.
It helps the implementation to adhere to the contract.

  Please note that these points were argued extensively on the Python
  types-sig a couple of years ago.
SIG archives tend to be non-searchable.
I, probably, will not dig in to summarize the results.
Even, if I do, this would be no garantee that I would be
convinced.


Let me stress my point of view. Maybe, we are not too far away
from one another:

  * I like clear specifications (as you do)

  * The specification has more value, when its implementations
adhere to it (you probably will agree).

  * A documentation about an existing system is more
valuable, when it states what is rather than
what should be (here we may disagree).

I usually start by studying the documentation.
If it descibes what is, then I will recognize
early what does not fit my requirements and
can work around it.
If it describes what should be, I will
determine the deficiencies much later in my projects,
modifications are much more difficult and expensive.

  * Having the specification near the implementation
helps the implementors to adhere to it,
especially with long maintenance periods.
(Here we may disagree).

I believe in the value of well documented
source, in literate programming.


Dieter

___
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] fixing security problems HOW?

2000-11-28 Thread Robin Becker

In article [EMAIL PROTECTED], Robin Becker
[EMAIL PROTECTED] writes

Apparently, your "live" is a Z instance.
It is quite easy to forget the ZClass permission mapping
(or get it wrong). This may lead to strange permission
problems.
Which ZClass permission mapping? Anonymous seems to be able to 'view'.

The 'Manager' role can log in and do stuff, but even when I change the
permissions of Anonymous to be completely the same as for Manager I
don't get the same behaviour; ie anonymous is being asked to log in?

The problem I suppose is that /live/index_html is really a permission of
/live and I guess the permissions determining access etc are really in /
the object which cannot be traversed to :) 
well I upgraded my CVS version and everything started working again.
Mumble. If only I hadn't tried to get the new Python methods to work etc
etc dribble dribble.
-- 
Robin Becker

___
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] OracleStorage, and possibly others

2000-11-28 Thread Lalo Martins

On Tue, Nov 28, 2000 at 06:01:15PM -0800, Ender wrote:
 Lalo Martins wrote:
  
  Well, two betas of OracleStorage in one day, then a month and a
  half of silence. What's the status?
  
  What about the other Storage projects? BerkeleyStorage has been
  dead for an year, and I heard pretty nasty words about
  InterbaseStorage. What about someone who wanted to try to port
  OracleStorage to Postgres or some other RDBMS?
  
  Please help stamp out Data.fs! :-)
 
 i've been interested in doing a postgres storage, but i haven't been
 able to convince myself that it would be useful in practice at all. any
 suggestions?

Of course it would, for the same reasons as OracleStorage (eg
FileStorage/Data.fs is inefficient), plus PostgreSQL is free
and Oracle costs thousands of dollars. What's the doubt? :-)

[]s,
   |alo
   +
--
  Hack and Roll ( http://www.hackandroll.org )
The biggest site for whatever-it-is-that-we-are.


http://zope.gf.com.br/lalo   mailto:[EMAIL PROTECTED]
 pgp key: http://zope.gf.com.br/lalo/pessoal/pgp

Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar

___
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] ZPetterns implementation qustions

2000-11-28 Thread Itai Tavor

Hi,

I'm trying to figure out the right way to implement a set of classes 
and roles in ZPatterns. I asked some questions about this a while 
ago, and then went away and did some learning, but I'm stuck again 
and I'm afraid I need to ask more questions.

I have two types of actors - Person (with properties name, phone, 
email, password) and Organization (with properties name, phone, fax, 
business_number).

I also have two participants - Customer and Reseller. Each 
participant can be either a Person or an Organization.

The participants can fill several roles, like OrderingEntities, 
BillableEntities, etc.

Starting from the bottom, I create a Specialist for each role, each 
one with two virtual Racks - customerRack and ResellerRack, so I can 
refer to an OrderingEntity without caring if it's a Reseller or 
Customer.

My problem is in implementing the Participant Specialists and storing 
Participant and Actor classes. Do I create Specialists for the 
Actors? It seems to me that since there is either one Person or one 
Organization per Customer, then the actor object should be created in 
the Customers Specialist. So Customers will have 3 Racks - 
defaultRack (using Customer object), personRack (using Person object) 
and organizationRack (using Organization object). Does this make 
sense?

If this is a good way to do it, how do I handle creating and 
accessing the Person and Organization objects? Do I call 
personRack.newItem(newCustomerId) in the script that creates the 
customer? Or do I somehow do it in a SkinScript in defaultRack? And 
how do I get to the Person data? With an attribute provider? Or in 
the SkinScript:

WITH personRack.getItem(self.id) COMPUTE name=name, phone=phone, 
email=email, password=password, personObject=RESULT)

Also, if Actors are stored in the Specialists that implement the 
roles they participate as, there is no place to store methods that 
are common to an Actor regardless of role - for example, a method 
that checks if a password is secure enough and called when adding a 
Person object. So I either duplicate these methods in every 
Participant Specialist, or create more Specialists - which seems like 
a waste either way.

Another problem is how to edit these objects - if I have a form which 
includes fields for a Customer properties and for the properties of 
the Person object linked to that Customer, can I change the Person 
object from the Customer SkinScript? I don't think I can do this:

   WHEN OBJECT CHANGED STORE name, password USING
 
personObject.propertysheets.manage_changeProperties(name=self.name, 
password=self.password)

Right? Because name and password are not properties on the Customer 
DataSkin. So I have to call person.manage_changeProperties(...) in 
the method that changes Customer... it seems to me that I always end 
up doing object connections work in methods and the SkinScript can't 
help with anything :(


Hope this is not too convoluted...I'd really appreciate any help 
anyone can offer. The existing ZPatterns examples
all deal with fairly straightforward situations, but it's the more 
complex class relationships where the bears and tigers are hiding :)

Itai
-- 
Itai Tavor"Je sautille, donc je suis."
C3Works[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you haven't got anything"


___
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

2000-11-28 Thread Cees de Groot

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 )




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 )