Re: var_to_string

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Wed, Apr 25, 2012 at 09:35:52PM -0700, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > The attatched patch makes a solution to bug #31566 possible.
>      >
>      > It replaces the const char* with a struct string *
>      
>      I don't like the idea of doing this extra allocation, copying,
>      and deallocation if we can avoid it.  
>
> I'm not particularly happy with it either.
>      
>      One way, for example, would be to add a new var_* function that
>      returns the variable name and label together, keeping the string
>      cached as part of the struct variable.
>
> I can see that would work.  However, I don't like the idea of having the
> data and its presentation in the same structure.  I think we ought to
> start making an effort to keep them apart.

I think that it's better to think of it as a cache rather than a
violation of separation of data and presentation.

I don't have a better idea.  I suspect that in fact this is the
wrong place to worry about this separation.  To more properly
separate data and presentation in such a case, it would make more
sense to add a function to add a variable name to a cell in a
table, which would internally look at the setting and put the
properly formatted name (either as name or label or name+label)
int he cell.  And then ultimately it would be even better to
avoid making this decision at the time of table construction, so
that the user could, say, right-click on a particular table and
change the setting for a table that has already been output.