Hey Nathann and Jori,

On Thursday, January 21, 2016 at 3:14:09 AM UTC-6, Nathann Cohen wrote:
>
> > The former is when the Poset is acting as an adapter class, and the 
> latter 
> > is something where there either is no analog currently on the backend 
> (there 
> > might be no gain because there is no analog (di)graph function or 
> > translation cost). It depends on the situation and is just trying to be 
> > effective code. 
>
> What I (and probably Jori too) try to understand is what should be 
> implemented in HasseDiagram and what should be implemented in the 
> Poset class directly. 
>

Ah, I see what you're asking now. 

>
> Right now the development is designed in what I think is a really 
> senseless way: every features requires two new functions: 
> - One on HasseDiagram which does the job 
> - One on Poset which calls it 
>

> It looks like useless work (especially since users are discouraged to 
> use HasseDiagram). I got used to implement only one function when I 
> need only one function. 
>

   That is because you're also not thinking about the user interface. The 
Poset needs to be an adapter class because we do not want all of the 
methods of HasseDiagram, (really DiGraph) appearing in the tab completion 
of a poset. Moreover, we can pass through the adapter (the general labels) 
to the "unlabeled" integers, where comparisons are guaranteed to be really 
fast. Both of which justifies the extra wrapper functions (in fact, most of 
the work IMO is the extra docstrings).

>
> So far, the only reason I understood from conversations with Jori is 
> that the Poset constructor (which relies on UniqueRepresentation) is 
> too slow to be called too often. So Jori works on HasseDiagram 
> directly to avoid this cost.
>

IMO this is a separate issue from why we have the 2 distinct classes.

>
> While it makes sense on one's computer (I would probably do the same) 
> it just doesn't do to duplicate everything in Sage's own source code 
> just because the constructor is slow. 
>
> It's also not *code* duplication, just an extra layer of indirection (and 
some doc duplication in a sense).

Best,
Travis

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to