On 4/12/02 2:49 AM, "Toby Dickenson" <[EMAIL PROTECTED]>
wrote:
> 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 > "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 ;-)
Personally, I absolutely abhor the difference between
And
It's violently non-obvious and confusing, even to seasoned Zope developers
just glancing over code. So, personally, my bizarre style is to always
explicitly say 'expr="..."', but I try to avoid expr's where necessary to
make life simpler.
Fortunately, there's the happy land of TAL and TALES for me to play in these
days. :)
>> (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 is a good thing
> whether Summary is an attribute or method (and not at all bizarre). I agree
> that changing this would be disasterous.
I have to now admit to not having seen the proposal, I've just been
following along here and struggling to capture the meaning of "idempotent"
as it applies to Zope security, but I *think* I'm starting to grok it.
Since a search for idempotent on zope.org yields no results, I'm assuming
that your proposal isn't up there (or the catalog is up to its old charms ;)
But now, does this mean I have to go through and tag every method that might
cause a state change? Or might not?
> Im not sure whether you misunderstood the proposal, or just gave a poor
> example to explain why you thought the proposal is bad.
Since I haven't read the proposal, only the recent mail messages, I'm just
trying to get clearer understanding. Maybe I'm just having the same sort of
trouble with idempotent versus nonidempotent that I did with mutable and
immutable (for some reason, I unlearned the differences between the two
between CS and the real world, and invented new meanings around the word
'mute' instead of 'mutate').
> 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 = ''
>
> 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:
>
>
>
> or would you use
>
>
>
>
>
> ?
>
> (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.)
I think that it could be caught and reported as a Warning, but not an error.
It's been a common thing for a long time, and I think it would be bad to
label it as an "error". Warn first, slap later. :)
Now that I'm understanding things more, I never call non-idempotent methods
(I hope I'm using that term right) from DTML anymore, and when I did it was
always with a , with rare uses of direct name use
(), usually in regards to SQL methods. So, it was my
misunderstanding of the proposal.
Overall, I still don't know how I feel about the whole thing. It's good to
have Zope as secure as possible, but if putting that security makes it
suddenly much harder to develop for or upgrade to/for, I worry about the
support costs involved.
--
Jeffrey P Shell
www.cuemedia.com
___
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 )
