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

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> >Okay, asking some questions. Perhaps they're wrong, but I'm just
> >throwing them out.
> >
> >Wouldn't this be too implicit if you can just register against any class
> >directly? At least with this proposal you have to *say* something to 
> >make the class useable that way.
> 
> No, it's very explicit. You are saying that you are depending on an
> implementation, rather than an interface. You are saying that you
> don't care about supportingt alternate implementations and that you
> are willing to change your code if the implementation changes.

Okay, I can buy that, though it might become hairy if these references
happen from elsewhere in the codebase written by someone else. But this 
would be really dirty and the people who do this should be punished anyway
so they'll use interfaces.

> You are saying you want to be quicj and dirty. Everybody likes to
> get dirty once and a while. ;)
> 
> (Lately, as I've been thinking about how good Zope 2 is and supporting
> "scripters" and realizing that Zope 3 needs needs to be just as supportive 
> of
> that audience, I've come to realize that there's a place for quick and
> dirty programming. The trick is providing a clean evolution from
> dirty to clean.)

Exactly what I've been trying to express. Quick and dirty can give
instant gratification, which is encouraging. Then unfortunately 
with Zope 2, the Z shaped learning curve kicks in. If we can support
the instant gratification while keeping an evolution path open towards
cleaner code, that would be awesome. It would sell Zope 3 to
a very broad audience indeed.

> >Wouldn't it be rather complicated to make the interface registries
> >and lookup code now also work with classes? Code that just uses
> >interfaces sounds easier to optimize too.
> 
> Nope, not really.

All right. I just figured it would be easier to not having to change
the way this currently works. I saw before you're planning a geddon
in this domain anyway, so perhaps it is not a big deal.

> >Wouldn't it be conceptually confusing -- won't people wonder what the
> >difference is between a class and an interface even more? With this
> >proposal people still deal with interfaces and interfaces only.
> 
> I find the nonce interface idea to be far more confusing.
> It's a return to the funny Zope 2 magic name rules.

Sure, but it's pretty explicit about it. How is security going to work
if you do direct views to classes? I understood from Steve the methods
need to exist on the interface for the machinery to work.

> It treats a class as an interface in a far less honest way.
> 
> >How do you use schema with views against classes?
> 
> You don't.  When you want to use schema, you have an interface.

One risk then would be that the quick and dirty method needs interfaces
almost right away to get anything done. It would then not be
very useful to have views against classes. Or is there some way to
combine the two techniques easily?

> >Wouldn't the introspection code become more complicated
> >if it is now possible to define views against classes?
> 
> Nope. You won't get introspection with classes. When you want to
> support additional features, you can switch to using interfaces.

Hm. I'm not sure what the implications of this are.

> >Steve mentioned some issues with explicit placeholder interfaces which
> >don't specify all the methods. I may have misunderstood them, but 
> >isn't that a problem with using placeholder interfaces? It'll also
> >be harder to distinguish these from real marker interfaces.
> 
> Placeholoder interfaces don't help with security assertions.
> You'll have to make assertions on attributes directly. Maybe we'll
> arrange that trusted (file-system) views registered against classes
> won't have to go through security to get at object attributes.

Best would be a way to declare them trusted explicitly I guess. If
you don't, you won't get trusted, no matter that you use filesystem.

Regards,

Martijn