[Zope3-dev] Allowing views to be registered for classes ratherthan interfaces.

[Martijn Faassen]

Garrett Smith wrote:
> Martijn Faassen wrote:
> > Questions:
> > 
> > IFoo is going to be where? Which import statement from where? There's
> > also an __implements__ line you need to maintain. This is definitely
> > more overhead and things you can do wrong than just remembering how
> > to spell nonce. :)
> 
> Were it me, I'd throw the interface into the same module -- I'm an XPish
> fan, so I like to get things working then evolve.

Yes, it's more typing and more overhead, which is what I'm worrying about. 
It reminds me of where you can do:

print "Hello world" 

in Python, whereas in Java you have to please a lot of different subsystems
before you get that onto the screen.

If I have to explain to someone to do:

from zope.interface import Interface
from zope.interface import implements

class IFoo(Interface):
   pass # marker interface

class Foo:
   implements(IFoo)

   def hello(self):
       return "Hello world!"

instead of:

from zope.interface import nonceInterface

class Foo:
   nonceInterface()

   def hello(self):
       return "Hello world!"

that's more work to get started.

Of course this is a good argument for views directly on classes, as:

class Foo:
   def hello(self):
       return "Hello world!"

is even less stuff to explain.

> As far as maintaining implements(IFoo), this is the first unit test I
> write.

I'm talking quick and dirty here. People who are scripting away, want
stuff done now, and can't be bothered with interfaces. You can go tell
them they're wrong and they have to, and they won't do it anyway or move
on to the next system.

Many of us turn into scripters when the time pressure is very high.
Yes, I know the arguments about how you're going to pay for this
during maintenance, but sometimes you're willing to pay this price, too.

> Incidentally, this is an interesting angle. Python is so subject to
> typos, etc. that if a developer doesn't write test cases ASAP -- I
> *literally* mean ASAP -- he/she's going to get into trouble.

This is an exaggaration. I mean, sure, you may have trouble with typos,
but it's not the end of the world either. This starts to hurt when
evolving towards a larger system.

> This runs
> counter to the notion that Python is quick-and-dirty. I find that Python
> *forces* me to be a whole lot more systematic in my development than I
> am in Java or C++. Unit tests take the place of compile time checking,
> among providing other essentials.

Um, so because Python does force you into bondage
and discipline and lets you get away with stuff, it forces you to be
more systematic.

I'm a fan of unit tests. I use them myself a lot; I've even used them
for Javascript code. But Python does not force this on anyone, and I
think this has benefits.

> So where is the hapless Zope 3 developer going to end up without a
> *little* discipline?

Exactly. They won't become a non-hapless Zope 3 developer as they'll never
get the gratification of something working.

> Were I teaching someone Zope 3 development, I'd
> start out with a big disclaimer: "don't be lured into thinking this is a
> no-brainer just because you're using Python".

This would scare away lots of Pyton programmers. Of course learning a new
framework is not going to be a no-brainer. But saying this will really not
help Zope 3's reputation amongst Python programmers.

But besides this, lots of the people that will come into Zope 3 will
not be Python programmers in the first place. They will hardly be
programmers. If you have to explain interfaces and unit testing to them
before they see "Hello world" when they start out with Python, then this is
bad. So let's make sure that doesn't happen. The newbie programmer will
already have to learn about view/content separation and that will be hard
enough.

> > I also understood from Steve that marker interfaces won't work this
> > way, as the security machinery can get into the way. It needs to be
> > able to find the methods on the interface. Don't know the details
> > though. 
> 
> I don't know either. But I would argue that one way of doing something
> is better than two ways -- pick the best way and don't confuse
> developers with subtle options.

The point is that we should be trying to do a number of things:

  * support scripters/quick & dirty hacking

  * support clean engineering practices

  * support Pythonic coding

  * support a clean evolution path from the quick & dirty to the clean,
    while remaining Pythonic.

Regards,

Martijn