[Cubicweb] moving and renaming vreg & co

Sylvain Thénault sylvain.thenault at logilab.fr
Thu Sep 15 16:47:29 CEST 2011

On 15 septembre 16:33, aurélien campéas wrote:
> 2011/9/15 Adrien Di Mascio <adrien.dimascio at logilab.fr>
> > On 15/09/2011 13:27, Sylvain Thénault wrote:
> >
> >> After discussing a bit over the phone with Nico, it occured that the
> >> almost established vocabulary have a problem: in the literature,
> >> dispatching is about choosing a function or method according to given
> >> arguments, then to call it with those arguments. In our case, we don't
> >> do that, but rather pick the most appropriate object according to a
> >> context, which is then returned to the caller. This is slightly different,
> >> and we're afraid that if the 'dispatch' term is closer to what we
> >> achieve here, it may also give a wrong feeling on what it does (though
> >> technically speaking, once an object is selected, it's called with
> >> the context as argument, but this is usually a class instanciation).
> >>
> >> Any thoughs on this?
> >
> I see this difference as irrelevant because in practice the returned
> object's main entry point (method) is called right away (in other words and
> imho cubicweb's appobjects + selectors are actually predicate-based generic
> functions in disguise).
> Of course we already had a long discussion on this very topic and could not
> come to an agreement. Some people (notably Sylvain) insist on the separate
> object selection (encompassing instantiation) and subsequent usage
> thereafter as something that bears a specific value (I'm trying not to put
> the wrong words in other people's mouth, please correct me if this is
> wrong); whereas I see this as an excess implementation detail creeping over
> the underlying predicate dispatch + generic function notion.

And I'm still agree with myself after this discussion :)

There are several places where we need this distinction. I can think about
some places where views have to be manipulated before being rendered, but the
best exemple is *adapters*: it's common that the API proposed by an adapter
as several methods, and that we've to get the adapter first, then to call
various methods there and there.

Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list