On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote:

>On 4/11/02 7:55 AM, "Toby Dickenson" <[EMAIL PROTECTED]>

>Then you're lucky.  Usually, any time I see <dtml-var
>"someNonIdempotentMethod()">, I immediately change it to the name lookup
>call.  Don't blame me, I've been following this paradigm for years (since
>before there were expr's in DTML).  I would hate to have to special case
>those methods

OK, that kills the second half of my proposal.

(I still think your style is bizarre though ;-)

> (which I use a lot, usually as accessors, ie:
>def Summary(self):
>    return self.title + self._description

Aha! maybe not!

That example method definitely is idempotent. Under my proposal it should not 
be declared non-idempotent, and would not have restricted dtml-name-lookup 
semantics. I agree being able to write <dtml-var Summary> is a good thing 
whether Summary is an attribute or method (and not at all bizarre). I agree 
that changing this would be disasterous.

Im not sure whether you misunderstood the proposal, or just gave a poor 
example to explain why you thought the proposal is bad.....

My proposal only affects method which have been declared to be 
non-idempotent. This declaration would only be added to methods that change 
externally visible state (in ZODB, Filesystem etc) or have external side 
effects (such as sending an email)

Here is a differnet example. Suppose you write a method:

def setEmptyTitle(self):
    self.title = '<empty>'

How would you call it from dtml. I think the 'right' answer is that you 
generally wouldnt call this method from dtml. From a PythonScript maybe, but 
not dtml. However if you did call if from dtml, would you still be using the 
name-lookup form, such as:

<dtml-var setEmptyTitle>

or would you use

<dtml-call setEmptyTitle>
<dtml-call "setEmptyTitle()">
<dtml-var "setEmptyTitle()">


(Im not going to argue that anyone is 'wrong' to prefer the first form in 
this case. Its my *personal* preference that calling non-idempotent methods 
using the name-lookup form should be caught and reported as an error.... I am 
wondering whether this preference is shared.)

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

Reply via email to