Lalo Martins wrote:
> > How could someone understand this when you're finished with it?
> Perfectly clearly for anyone used to functional programming;
> I'd even say, clear on first sight. A lot easier to understand
> and maintain than a separate method.
OK, I give. I think this would be fine in a Python (or external)
method. But I don't share your opinion that it should be exposed in
> > Isn't this much more understandable as an external method explicitly?
> No. And external methods should definitely be phased out as
> much as possible, they defeat one of the major advantages of
> Zope (everything is manageable trought the web).
Agreed on the point about external methods. Python methods should
succeed them. And if they do succeed them, I would like to see the
functional built-ins exposed. It would be a shame to not have them if
their use doesn't impact security.
> Your method, in particular, is worse to understand than my
> one-liner, specially for anyone who uses functional programming
> seriously; but even other people would have to reason for a
> few minutes to understand what you're appending to that poor
> list and why.
I can see that argument... it depends on the reader, I suppose. I
wouldn't complain much actually if the Python code had functional stuff
in it. It's having it in DTML that bugs me, for reasons that have to do
with separating HTML-like stuff from the stuff that actually runs the
site under the hood.
> > Maybe they should... it would be nice. I'm not sure why they're not in
> > Python Methods, other than Evan tried to make the security inherent in
> > Python methods as close to DTML as he could. I use map a lot. I don't
> > use lambda unless I really, really have to. Reduce and filter.. eh. I
> > dunno. They're sort of on the periphery of usefulness.
> I respect the fact that you have your opinion where DTML is
> going and where it should go and where it shouldn't. But I
> don't think it is an excuse to cripple it. It is, instead, your
> opinion, as much as mine is mine.
> Yes, expressions make DTML less clear and walk around caching.
> No, they shouldn't be banned. They're useful. Ban them and all
> you get is either a code fork or a considerable number of lost
I didn't say that we should ban them, I said they shouldn't have been
introduced in the first place. We can't ban them now, we know that.
> You compare these to ASP, PHP or Perl. I compare them to
> __getattr__, __getitem__, __call__ and others on Python, and to
> operator overloading in C++.
I compare them to ASP and PHP (not perl.. maybe embperl or PerlScript,
but not perl), because these are languages that encourage the use of
so-called "business logic" inside HTML, along with so-called
"presentation logic". Whatever you name them, I like to keep them as
separate as possible so designers don't shirk in fear or mess things up
when they need to navigate around hairy constructs in code. I've found
that separating them also lets you shift UI elements more easily.
It's clear that you don't share my opinion, nor do the other 99 million
people who use ASP or PHP. But I'm on the more moderate side of things,
believe it or not...you should really talk to some other folks here,
you'd argue for hours. :-)
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -