Review Request 122278: Additional changes in section handling
Inge Wallin
inge at lysator.liu.se
Thu Jan 29 13:16:25 GMT 2015
On Thursday, January 29, 2015 14:11:39 Inge Wallin wrote:
> On Thursday, January 29, 2015 12:57:35 Denis Kuplyakov wrote:
> > > On Янв. 27, 2015, 7:34 п.п., Camilla Boemann wrote:
> > > > libs/kotext/KoSectionManager.cpp, line 120
> > > > <https://git.reviewboard.kde.org/r/122278/diff/1/?file=345390#file3453
> > > > 90
> > > > line120>> >
> > > >
> > > > why no long const ?
> > >
> > > Denis Kuplyakov wrote:
> > > I don't know why, but QHash<T,Q>::find() isn't const. Thats why I
> > > can't make this function const and possibleNewName() too as
> > > dependant.>
> > >
> > > Denis Kuplyakov wrote:
> > > Ohh, I see constFind there. Why they made it such way? Anyway, will
> > > fix this.>
> > >
> > > Denis Kuplyakov wrote:
> > > There is a sectionNames() call, that updates internal data, to
> > > prevent
> > > using of invalidated one. So we can't put const here.>
> > >
> > > Friedrich W. H. Kossebau wrote:
> > > Could the members which hold that data that is only lazily
> > > fetched/updated be tagged with `mutable` perhaps? Problem with
> > > non-const get-methods is that this escalates up in the call
> > > hierarchy, i.e. any other method which uses this method now also
> > > needs to be non-const. Which is not nice, because it spoils the
> > > usefulness of const, which should protect against unintended data
> > > modification. Which lazily updated data surely is not, that's e.g.
> > > why there is `mutable`.>
> > >
> > > Denis Kuplyakov wrote:
> > > Can you post me some link, where I can read about what you mean
> > > under
> > > mutable?>
> > >
> > > Friedrich W. H. Kossebau wrote:
> > > Any good physical C++ book, hard to link ;) (no idea about what
> > > related ebooks there are)
> > >
> > > Hm, perhaps this here gives you a start:
> > > http://en.cppreference.com/w/cpp/language/cv>
> > >
> > > Elvis Stansvik wrote:
> > > http://en.cppreference.com/w/cpp/language/cv - "mutable - applies to
> > > non-static class members of non-reference non-const type and
> > > specifies that the member does not affect the externally visible
> > > state of the class. mutable members of const classes are modifiable
> > > (Note: the C++ language grammar treats mutable as a
> > > storage-class-specifier, but it does not affect storage class)".
> > > Wikipedia has a slightly less technical description (second
> > > example):
> > > http://en.wikipedia.org/wiki/Immutable_object#C.2B.2B>
> > >
> > > Denis Kuplyakov wrote:
> > > I have tried to use mutable with no luck. I doesn't understand how
> > > can
> > > I properly apply it in my case: isValidNewName() calls
> > > sectionNames()
> > > of its private part, and it calls update() public method. It is
> > > absolutely unlogic to make update() const function. And also two
> > > subsequent calls of isValidNewName() could give you different
> > > results, even if KoSectionManager isn't changed. You can create a
> > > section between them without referencing anywhere KoSectionManager
> > > (creating KoSection with QTextCursor, will get document associated
> > > KoSectionManager by pointer, and update() of it will be called and
> > > that will be done regardless of you local entity of KoSectionManager
> > > is const or not (which is pointed)). And KoSectionManager isn't
> > > supposed to be part of some other class, as I think. It is created
> > > dynamically and only links to it are stored.>
> > >
> > > Camilla Boemann wrote:
> > > ah yes, you are right it can't be applied to this case. Hmmm why do
> > > sections even have names, and why do they then have to be unique -
> > > surely we are not exposing some odf attribute?
>
> 19.835.14 <text:section>
> The text:name attribute specifies a unique name for a section.
> The text:name attribute is usable with the following element: <text:section>
> 5.4.
> The text:name attribute has the data type string 18.2.
>
> (Note the beautiful typo in the heading where it says text:section instead
> of text:name. :) )
>
> It does not say that it has to have a name, but if it has, it has to be
> unique. It does also not say that it does *not* have to have a name, so
> it's unclear whether the name is obligatory or optional.
Wait...
5.4 <text:section>
5.4.1 General
The <text:section> element represents a named region of content in a document.
So I guess it does indeed have to have a name.
More information about the calligra-devel
mailing list