Re: A singleton LyX class, 1st steps
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus This moves the lastfiles global variable into LyX and makes Angus emergencyCleanup a non-static member function. + * BufferView_pimpl.C (loadLyXFile): + * MenuBackend.C (expandLastfiles): + * bufferlist.C (MenuWrite, QuitLyX): + lastfiles is no longer a global variable. + Access through LyX::ref().lastfiles(), LyX::cref().lastfiles(). + For my edification: could you explain to me why this ref() and cref() thingy is needed? This looks ugly. Maybe is it just that I do not really understand what a singleton class is... JMarc
Re: A singleton LyX class, 1st steps
Jean-Marc Lasgouttes wrote:
Angus This moves the lastfiles global variable into LyX and makes
Angus emergencyCleanup a non-static member function.
+ * BufferView_pimpl.C (loadLyXFile):
+ * MenuBackend.C (expandLastfiles):
+ * bufferlist.C (MenuWrite, QuitLyX):
+ lastfiles is no longer a global variable.
+ Access through LyX::ref().lastfiles(), LyX::cref().lastfiles().
+
For my edification: could you explain to me why this ref() and
cref() thingy is needed? This looks ugly.
Maybe is it just that I do not really understand what a singleton
class is...
Here is a stripped down version of the class.
class LyX {
public:
static void exec(int argc, char * argv[]) {
singleton_.reset(new LyX);
singleton_-priv_exec(argc, argv);
}
static LyX ref(){ return * singleton_.get(); }
static LyX const cref() { return * singleton_.get(); }
private:
static boost::scoped_PtrLyX singleton_;
LyX();
void priv_exec(int argc, char * argv[]);
// Not implemented
LyX(LyX const );
void operator=(LyX const );
};
main.C starts it all off with
in main(int argc, char * argv[]) {
LyX::exec(argc, argv);
return 0;
};
Thereafter, anything else can get either a 'LyX const ' or a 'LyX '
to the single existing LyX variable, stored in LyX::singleton_ by
calls to either LyX::cref() or to LyX::ref(), respectively.
There is no such thing as a const static function, so we can't
overload a single name like this:
class LyX {
public:
static LyX get() { return * singleton_.get(); }
static LyX const get() const { return * singleton_.get(); }
};
Clearer now?
--
Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 10:25:02AM +0100, Angus Leeming wrote:
Maybe is it just that I do not really understand what a singleton
class is...
Here is a stripped down version of the class.
I still don't understand why you don't use a namespace.
class LyX {
public:
static void exec(int argc, char * argv[]) {
singleton_.reset(new LyX);
singleton_-priv_exec(argc, argv);
}
static LyX ref(){ return * singleton_.get(); }
static LyX const cref() { return * singleton_.get(); }
private:
static boost::scoped_PtrLyX singleton_;
LyX();
void priv_exec(int argc, char * argv[]);
// Not implemented
LyX(LyX const );
void operator=(LyX const );
};
main.C starts it all off with
in main(int argc, char * argv[]) {
LyX::exec(argc, argv);
return 0;
};
in the .h:
namespace lyxglobal {
void exec(int argc, char * argv[]);
LyX ref();
LyX const cref();
}
in the .C:
namespace {
LyX singleton_;
void priv_exec(int argc, char * argv[]);
}
main.C starts it all off with
int main(int argc, char * argv[]) {
lyxglobal::exec(argc, argv);
return 0;
}
Slimmer interface, same function.
Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz wrote:
I still don't understand why you don't use a namespace.
in the .h:
namespace lyxglobal {
void exec(int argc, char * argv[]);
LyX ref();
LyX const cref();
}
Maybe nest the namespace
namespace lyx {
namespace global {
void exec(int argc, char * argv[]);
LyX ref();
LyX const cref();
} // namespace global
} // namespace lyx
I'd still have to define a LyX class in the .h file, (so that the
rest of the code can access the LyX member functions) and make exec()
a friend function so that it can access the (private) LyX constructor.
But yes, this is possible. Note that the LyX class interface is
currently bloated with a whole heap of private member functions that
should really belong in an anonymous namespace in the .C file.
So, let's just call this an iterative procedure. Lars' baby-crawl as
opposed to André's giant-steps?
After all, I was interested primarily in removing the BufferView
cache...
Now that it is gone, you might like to consider replacing all of
mathed's calls to
void BufferView::updateInset(InsetOld const *);
with the equivalent call through LyX:
LyX::cref().updateInset(this);
Which will 'just work' when we eventually have multiple BufferViews.
--
Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 10:47:50AM +0100, Angus Leeming wrote:
Andre Poenitz wrote:
I still don't understand why you don't use a namespace.
in the .h:
namespace lyxglobal {
void exec(int argc, char * argv[]);
LyX ref();
LyX const cref();
}
Maybe nest the namespace
namespace lyx {
namespace global {
Fine with me.
void exec(int argc, char * argv[]);
LyX ref();
LyX const cref();
} // namespace global
} // namespace lyx
I'd still have to define a LyX class in the .h file, (so that the
rest of the code can access the LyX member functions) and make exec()
a friend function so that it can access the (private) LyX constructor.
The functions could be free functions.
But yes, this is possible. Note that the LyX class interface is
currently bloated with a whole heap of private member functions that
should really belong in an anonymous namespace in the .C file.
So, let's just call this an iterative procedure. Lars' baby-crawl as
opposed to André's giant-steps?
Fine. I just don't want you let fall in a state of desperation because
everything seems to be perfect ;-)
After all, I was interested primarily in removing the BufferView
cache...
Well done.
Now that it is gone, you might like to consider replacing all of
mathed's calls to
void BufferView::updateInset(InsetOld const *);
with the equivalent call through LyX:
LyX::cref().updateInset(this);
Or lyx::global::updateInset(this) ;-)
[Which suspiciously feels like using 'current_view' *cough*]
Which will 'just work' when we eventually have multiple BufferViews.
Good.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: A singleton LyX class, 1st steps
Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] But isn't... Hmmm, so you're suggesting a bunch of free functions which provide a world-visble interface to class LyX's member variables, this class itself being hidden away in the .C file. I can see it is possible. Why is it 'preferable'? Angus, the C++ dinosaur.
Re: A singleton LyX class, 1st steps
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] Angus But isn't... Angus Hmmm, so you're suggesting a bunch of free functions which Angus provide a world-visble interface to class LyX's member Angus variables, this class itself being hidden away in the .C file. But class LyX's member variables are just a bunch of global variables hidden in a `singleton class' just for the sake of using a buzzword, aren't they? Seriously, I do not understand what is the purpose of a singleton class versus global variables hidden in some namespace. JMarc
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] But isn't... I know. Hmmm, so you're suggesting a bunch of free functions which provide a world-visble interface to class LyX's member variables, this class itself being hidden away in the .C file. Yes. I can see it is possible. Why is it 'preferable'? Free functions provide (often...) better encapsulation (Scott Meyers?). Have a look at the resulting .h files in both cases. Which one is slimmer? Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] But isn't... | I know. Hmmm, so you're suggesting a bunch of free functions which provide a world-visble interface to class LyX's member variables, this class itself being hidden away in the .C file. | Yes. I can see it is possible. Why is it 'preferable'? | Free functions provide (often...) better encapsulation (Scott Meyers?). | Have a look at the resulting .h files in both cases. | Which one is slimmer? But when comparing APIs you have to take the free functions into account. So the functions API does not get slimmer, but you get less dependencies and better encapsulation. -- Lgb
Re: A singleton LyX class, 1st steps
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] But isn't... | I know. Hmmm, so you're suggesting a bunch of free functions which provide a world-visble interface to class LyX's member variables, this class itself being hidden away in the .C file. | Yes. I can see it is possible. Why is it 'preferable'? | Free functions provide (often...) better encapsulation (Scott Meyers?). Btu not if they operatoe on global variables... then you do not gain anything. -- Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 12:36:52PM +0200, Jean-Marc Lasgouttes wrote: But class LyX's member variables are just a bunch of global variables hidden in a `singleton class' just for the sake of using a buzzword, aren't they? Sort of. The problem is there are languages (like Java) where using such things is necessary as the alternative does not exist (free functions). Now there is a tendency to deploy knowledge gained in one area in an other, just because it works, not because it is the best solution. That's only human I suppose. Andre' [Of course there are limits to this approach. I recently really got angry when one of the 'leading German computer magazines' came up with a benchmark showing that C++ is _slower_ than Java. Well, the Java stuff they tested was not exactly perfect, but the equivalent C++ code was so abysmal that I would not use that page to wipe my backside. And, of course, the test was fair as the algorithm was identical.]
Re: A singleton LyX class, 1st steps
Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] Angus But isn't... Angus Hmmm, so you're suggesting a bunch of free functions which Angus provide a world-visble interface to class LyX's member Angus variables, this class itself being hidden away in the .C file. But class LyX's member variables are just a bunch of global variables hidden in a `singleton class' just for the sake of using a buzzword, aren't they? Seriously, I do not understand what is the purpose of a singleton class versus global variables hidden in some namespace. The order of destruction of static variables is undefined. If they are encapsulated inside a class then this order is defined --- by us. However, I don't think that any of this is really anything more than aesthetics. I _may_ go down this route, but I'm much more interested in * finish off InsetExternal, * think about killing off InsetGraphics * think about moving the LaTeX part of InsetInclude into InsetExternal * think about a FileName class that can handle environment variables * clean up InsetBibtex * creating a BiblioCache analogous to GraphicsCache, stripping out all our home made citation stuff and using BibTeX to do the hard work. Oh, and before I get carried away, I should finish off the Controller cleanup... -- Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 12:08:53PM +0100, Angus Leeming wrote: Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Andre Poenitz wrote: Or lyx::global::updateInset(this) ;-) [Which suspiciously feels like using 'current_view' *cough*] Angus But isn't... Angus Hmmm, so you're suggesting a bunch of free functions which Angus provide a world-visble interface to class LyX's member Angus variables, this class itself being hidden away in the .C file. But class LyX's member variables are just a bunch of global variables hidden in a `singleton class' just for the sake of using a buzzword, aren't they? Seriously, I do not understand what is the purpose of a singleton class versus global variables hidden in some namespace. The order of destruction of static variables is undefined. If they are encapsulated inside a class then this order is defined --- by us. Statics in a single file will be destructed in last-to-first order. However, I don't think that any of this is really anything more than aesthetics. I _may_ go down this route, but I'm much more interested in * finish off InsetExternal, * think about killing off InsetGraphics * think about moving the LaTeX part of InsetInclude into InsetExternal * think about a FileName class that can handle environment variables * clean up InsetBibtex * creating a BiblioCache analogous to GraphicsCache, stripping out all our home made citation stuff and using BibTeX to do the hard work. Oh, and before I get carried away, I should finish off the Controller cleanup... So do that and I take care of this namespace business. Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz [EMAIL PROTECTED] writes: | Statics in a single file will be destructed in last-to-first order. One problem is still that several of the global varialbes cannot be static, they need more information before they can be initialized. That is easily solved with a class. Also pre-main construction of complex objects often have problems. -- Lgb
Re: A singleton LyX class, 1st steps
Lars Gullik Bjønnes wrote:
I can see it is possible. Why is it 'preferable'?
| Free functions provide (often...) better encapsulation (Scott
| Meyers?).
Btu not if they operatoe on global variables... then you do not gain
anything.
Where do you stand on the particular design under discussion?
We're talking about free functions that provide access to a class's
member variables. The class declaration, definition and single
instance is hidden entirely inside a .C file. Whether it is a
singleton class or not is nothing but an implementation detail.
namespace lyx {
namespace global {
/** start the whole thing off, instantiating the
* class variable that will store lastfiles,
* lyxrc, converters, formats
*
void exec(int argc, char * argv[]);
LastFiles lastfiles();
LyXRC const lyxrc();
Converters const converters();
Formats const formats();
} // namespace global
} // namespace lyx
Is this a 'good design'? One downer --- it is impossible to provide
const reference and reference accessor functions with the same name.
--
Angus
Re: A singleton LyX class, 1st steps
Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Statics in a single file will be destructed in last-to-first
| order.
One problem is still that several of the global varialbes cannot be
static, they need more information before they can be initialized.
That is easily solved with a class.
Or by an accessor function:
boost::scoped_ptrControllers controllers_;
Controllers const controllers() {
if (!controllers_.get())
controllers_.reset(new Controllers);
return *controllers_.get();
}
--
Angus
Re: A singleton LyX class, 1st steps
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: I can see it is possible. Why is it 'preferable'? | Free functions provide (often...) better encapsulation (Scott | Meyers?). Btu not if they operatoe on global variables... then you do not gain anything. | Where do you stand on the particular design under discussion? | We're talking about free functions that provide access to a class's | member variables. Free functions should ideally not access class variables, the functions should be free only when they don't need access to the class variables and only need the class's public interface for implementation. (and then of course no class variables should be public.) This is the encapsulation part. (or course this can be simulated with anon namespaces, but then the design is more open and access to the variables are not as controlled.) So, I guess, all in all I am more in favor of class variables than variables in a anon namespace. -- Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote: Free functions should ideally not access class variables, This assumes that the class is not a random collection of individual thing - which it is in our case - but something real. the functions should be free only when they don't need access to the class variables and only need the class's public interface for implementation. (and then of course no class variables should be public.) This is the encapsulation part. (or course this can be simulated with anon namespaces, but then the design is more open and access to the variables are not as controlled.) Handing out non-const refs to members is completely destroying the type of encapsulation you speak of here (access). The two things are functionality-wise completely equivalent. But: In the class solution you have to show private members like 'last_files_' in the .h, whereas in the namespace solution they are hidden in the .C. So this is better encapsulation of the visibility type. So, I guess, all in all I am more in favor of class variables than variables in a anon namespace. Which is a bit of a surprise to me. We have a draw when it comes to encapsulating access and a point for namespaces when it comes to not exposing implementation details. Well. So let's stay with the class as it is. I am not religious about this bit. Andre'
Re: A singleton LyX class, 1st steps
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus However, I don't think that any of this is really anything more Angus than aesthetics. I _may_ go down this route, but I'm much more Angus interested in [...] Of course :) JMarc
Re: A singleton LyX class, 1st steps
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote: Free functions should ideally not access class variables, | This assumes that the class is not a random collection of individual | thing - which it is in our case - but something real. then perhaps each of them should be its own singleton? the functions should be free only when they don't need access to the class variables and only need the class's public interface for implementation. (and then of course no class variables should be public.) This is the encapsulation part. (or course this can be simulated with anon namespaces, but then the design is more open and access to the variables are not as controlled.) | Handing out non-const refs to members is completely destroying the type | of encapsulation you speak of here (access). Only in part. | The two things are functionality-wise completely equivalent. | But: In the class solution you have to show private members like | 'last_files_' in the .h, whereas in the namespace solution they are | hidden in the .C. So this is better encapsulation of the visibility | type. The class solution for this is pimpl. -- Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 03:03:06PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote: Free functions should ideally not access class variables, | This assumes that the class is not a random collection of individual | thing - which it is in our case - but something real. then perhaps each of them should be its own singleton? Or a static variable in a namespace. *eg* the functions should be free only when they don't need access to the class variables and only need the class's public interface for implementation. (and then of course no class variables should be public.) This is the encapsulation part. (or course this can be simulated with anon namespaces, but then the design is more open and access to the variables are not as controlled.) | Handing out non-const refs to members is completely destroying the type | of encapsulation you speak of here (access). Only in part. It is _exactly_ the same whether I have a reference to a member of a singleton or whether I have a reference to some static variable in some namespace. There is not a wee bit more encapsulation on the class side. | The two things are functionality-wise completely equivalent. | But: In the class solution you have to show private members like | 'last_files_' in the .h, whereas in the namespace solution they are | hidden in the .C. So this is better encapsulation of the visibility | type. The class solution for this is pimpl. I have been waiting for this one. We'd better stop now. Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 03:03:06PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote: Free functions should ideally not access class variables, | This assumes that the class is not a random collection of individual | thing - which it is in our case - but something real. then perhaps each of them should be its own singleton? | Or a static variable in a namespace. What would be the point in that? we don't use static variables in file scope, we use anon namespaces there. | Handing out non-const refs to members is completely destroying the type | of encapsulation you speak of here (access). Only in part. | It is _exactly_ the same whether I have a reference to a member of a | singleton or whether I have a reference to some static variable in some | namespace. There is not a wee bit more encapsulation on the class side. except that you can modify/controll access to variables with accessors. The class solution for this is pimpl. | I have been waiting for this one. | We'd better stop now. ok with me. -- Lgb
Re: A singleton LyX class, 1st steps
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> This moves the lastfiles global variable into LyX and makes Angus> emergencyCleanup a non-static member function. + * BufferView_pimpl.C (loadLyXFile): + * MenuBackend.C (expandLastfiles): + * bufferlist.C (MenuWrite, QuitLyX): + lastfiles is no longer a global variable. + Access through LyX::ref().lastfiles(), LyX::cref().lastfiles(). + For my edification: could you explain to me why this ref() and cref() thingy is needed? This looks ugly. Maybe is it just that I do not really understand what a singleton class is... JMarc
Re: A singleton LyX class, 1st steps
Jean-Marc Lasgouttes wrote:
> Angus> This moves the lastfiles global variable into LyX and makes
> Angus> emergencyCleanup a non-static member function.
>
> + * BufferView_pimpl.C (loadLyXFile):
> + * MenuBackend.C (expandLastfiles):
> + * bufferlist.C (MenuWrite, QuitLyX):
> + lastfiles is no longer a global variable.
> + Access through LyX::ref().lastfiles(), LyX::cref().lastfiles().
> +
>
> For my edification: could you explain to me why this ref() and
> cref() thingy is needed? This looks ugly.
>
> Maybe is it just that I do not really understand what a singleton
> class is...
Here is a stripped down version of the class.
class LyX {
public:
static void exec(int argc, char * argv[]) {
singleton_.reset(new LyX);
singleton_->priv_exec(argc, argv);
}
static LyX & ref(){ return * singleton_.get(); }
static LyX const & cref() { return * singleton_.get(); }
private:
static boost::scoped_Ptr singleton_;
LyX();
void priv_exec(int argc, char * argv[]);
// Not implemented
LyX(LyX const &);
void operator=(LyX const &);
};
main.C starts it all off with
in main(int argc, char * argv[]) {
LyX::exec(argc, argv);
return 0;
};
Thereafter, anything else can get either a 'LyX const &' or a 'LyX &'
to the single existing LyX variable, stored in LyX::singleton_ by
calls to either LyX::cref() or to LyX::ref(), respectively.
There is no such thing as a const static function, so we can't
overload a single name like this:
class LyX {
public:
static LyX & get() { return * singleton_.get(); }
static LyX const & get() const { return * singleton_.get(); }
};
Clearer now?
--
Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 10:25:02AM +0100, Angus Leeming wrote:
> > Maybe is it just that I do not really understand what a singleton
> > class is...
>
> Here is a stripped down version of the class.
I still don't understand why you don't use a namespace.
> class LyX {
> public:
> static void exec(int argc, char * argv[]) {
> singleton_.reset(new LyX);
> singleton_->priv_exec(argc, argv);
> }
> static LyX & ref(){ return * singleton_.get(); }
> static LyX const & cref() { return * singleton_.get(); }
> private:
> static boost::scoped_Ptr singleton_;
> LyX();
> void priv_exec(int argc, char * argv[]);
> // Not implemented
> LyX(LyX const &);
> void operator=(LyX const &);
> };
>
> main.C starts it all off with
> in main(int argc, char * argv[]) {
> LyX::exec(argc, argv);
> return 0;
> };
in the .h:
namespace lyxglobal {
void exec(int argc, char * argv[]);
LyX & ref();
LyX const & cref();
}
in the .C:
namespace {
LyX singleton_;
void priv_exec(int argc, char * argv[]);
}
main.C starts it all off with
int main(int argc, char * argv[]) {
lyxglobal::exec(argc, argv);
return 0;
}
Slimmer interface, same function.
Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz wrote:
> I still don't understand why you don't use a namespace.
> in the .h:
> namespace lyxglobal {
> void exec(int argc, char * argv[]);
> LyX & ref();
> LyX const & cref();
> }
Maybe nest the namespace
namespace lyx {
namespace global {
void exec(int argc, char * argv[]);
LyX & ref();
LyX const & cref();
} // namespace global
} // namespace lyx
I'd still have to define a LyX class in the .h file, (so that the
rest of the code can access the LyX member functions) and make exec()
a friend function so that it can access the (private) LyX constructor.
But yes, this is possible. Note that the LyX class interface is
currently bloated with a whole heap of private member functions that
should really belong in an anonymous namespace in the .C file.
So, let's just call this an iterative procedure. Lars' baby-crawl as
opposed to André's giant-steps?
After all, I was interested primarily in removing the BufferView
cache...
Now that it is gone, you might like to consider replacing all of
mathed's calls to
void BufferView::updateInset(InsetOld const *);
with the equivalent call through LyX:
LyX::cref().updateInset(this);
Which will 'just work' when we eventually have multiple BufferViews.
--
Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 10:47:50AM +0100, Angus Leeming wrote:
> Andre Poenitz wrote:
> > I still don't understand why you don't use a namespace.
>
> > in the .h:
> > namespace lyxglobal {
> > void exec(int argc, char * argv[]);
> > LyX & ref();
> > LyX const & cref();
> > }
>
> Maybe nest the namespace
> namespace lyx {
> namespace global {
Fine with me.
> void exec(int argc, char * argv[]);
> LyX & ref();
> LyX const & cref();
> } // namespace global
> } // namespace lyx
>
> I'd still have to define a LyX class in the .h file, (so that the
> rest of the code can access the LyX member functions) and make exec()
> a friend function so that it can access the (private) LyX constructor.
The functions could be free functions.
> But yes, this is possible. Note that the LyX class interface is
> currently bloated with a whole heap of private member functions that
> should really belong in an anonymous namespace in the .C file.
>
> So, let's just call this an iterative procedure. Lars' baby-crawl as
> opposed to André's giant-steps?
Fine. I just don't want you let fall in a state of desperation because
everything seems to be perfect ;-)
> After all, I was interested primarily in removing the BufferView
> cache...
Well done.
> Now that it is gone, you might like to consider replacing all of
> mathed's calls to
> void BufferView::updateInset(InsetOld const *);
> with the equivalent call through LyX:
> LyX::cref().updateInset(this);
Or lyx::global::updateInset(this) ;-)
[Which suspiciously feels like using 'current_view' *cough*]
> Which will 'just work' when we eventually have multiple BufferViews.
Good.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: A singleton LyX class, 1st steps
Andre Poenitz wrote: > Or lyx::global::updateInset(this) ;-) > [Which suspiciously feels like using 'current_view' *cough*] But isn't... Hmmm, so you're suggesting a bunch of free functions which provide a world-visble interface to class LyX's member variables, this class itself being hidden away in the .C file. I can see it is possible. Why is it 'preferable'? Angus, the C++ dinosaur.
Re: A singleton LyX class, 1st steps
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Andre Poenitz wrote: >> Or lyx::global::updateInset(this) ;-) [Which suspiciously feels >> like using 'current_view' *cough*] Angus> But isn't... Angus> Hmmm, so you're suggesting a bunch of free functions which Angus> provide a world-visble interface to class LyX's member Angus> variables, this class itself being hidden away in the .C file. But class LyX's member variables are just a bunch of global variables hidden in a `singleton class' just for the sake of using a buzzword, aren't they? Seriously, I do not understand what is the purpose of a singleton class versus global variables hidden in some namespace. JMarc
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: > Andre Poenitz wrote: > > Or lyx::global::updateInset(this) ;-) > > [Which suspiciously feels like using 'current_view' *cough*] > But isn't... I know. > Hmmm, so you're suggesting a bunch of free functions which provide a > world-visble interface to class LyX's member variables, this class > itself being hidden away in the .C file. Yes. > I can see it is possible. Why is it 'preferable'? Free functions provide (often...) better encapsulation (Scott Meyers?). Have a look at the resulting .h files in both cases. Which one is slimmer? Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: >> Andre Poenitz wrote: >> > Or lyx::global::updateInset(this) ;-) >> > [Which suspiciously feels like using 'current_view' *cough*] >> But isn't... > | I know. > >> Hmmm, so you're suggesting a bunch of free functions which provide a >> world-visble interface to class LyX's member variables, this class >> itself being hidden away in the .C file. > | Yes. > >> I can see it is possible. Why is it 'preferable'? > | Free functions provide (often...) better encapsulation (Scott Meyers?). > | Have a look at the resulting .h files in both cases. | Which one is slimmer? But when comparing APIs you have to take the free functions into account. So the functions API does not get slimmer, but you get less dependencies and better encapsulation. -- Lgb
Re: A singleton LyX class, 1st steps
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Oct 15, 2003 at 11:29:56AM +0100, Angus Leeming wrote: >> Andre Poenitz wrote: >> > Or lyx::global::updateInset(this) ;-) >> > [Which suspiciously feels like using 'current_view' *cough*] >> But isn't... > | I know. > >> Hmmm, so you're suggesting a bunch of free functions which provide a >> world-visble interface to class LyX's member variables, this class >> itself being hidden away in the .C file. > | Yes. > >> I can see it is possible. Why is it 'preferable'? > | Free functions provide (often...) better encapsulation (Scott Meyers?). Btu not if they operatoe on global variables... then you do not gain anything. -- Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 12:36:52PM +0200, Jean-Marc Lasgouttes wrote: > But class LyX's member variables are just a bunch of global variables > hidden in a `singleton class' just for the sake of using a buzzword, > aren't they? Sort of. The problem is there are languages (like Java) where using such things is necessary as the alternative does not exist (free functions). Now there is a tendency to deploy knowledge gained in one area in an other, just because it works, not because it is the best solution. That's only human I suppose. Andre' [Of course there are limits to this approach. I recently really got angry when one of the 'leading German computer magazines' came up with a benchmark showing that C++ is _slower_ than Java. Well, the Java stuff they tested was not exactly perfect, but the "equivalent C++ code" was so abysmal that I would not use that page to wipe my backside. And, of course, the test was "fair" as the algorithm was "identical".]
Re: A singleton LyX class, 1st steps
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Andre Poenitz wrote: >>> Or lyx::global::updateInset(this) ;-) [Which suspiciously feels >>> like using 'current_view' *cough*] > Angus> But isn't... > > Angus> Hmmm, so you're suggesting a bunch of free functions which > Angus> provide a world-visble interface to class LyX's member > Angus> variables, this class itself being hidden away in the .C > file. > > But class LyX's member variables are just a bunch of global > variables hidden in a `singleton class' just for the sake of using a > buzzword, aren't they? > > Seriously, I do not understand what is the purpose of a singleton > class versus global variables hidden in some namespace. The order of destruction of static variables is undefined. If they are encapsulated inside a class then this order is defined --- by us. However, I don't think that any of this is really anything more than aesthetics. I _may_ go down this route, but I'm much more interested in * finish off InsetExternal, * think about killing off InsetGraphics * think about moving the LaTeX part of InsetInclude into InsetExternal * think about a FileName class that can handle environment variables * clean up InsetBibtex * creating a BiblioCache analogous to GraphicsCache, stripping out all our home made citation stuff and using BibTeX to do the hard work. Oh, and before I get carried away, I should finish off the Controller cleanup... -- Angus
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 12:08:53PM +0100, Angus Leeming wrote: > Jean-Marc Lasgouttes wrote: > > >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > > > Angus> Andre Poenitz wrote: > >>> Or lyx::global::updateInset(this) ;-) [Which suspiciously feels > >>> like using 'current_view' *cough*] > > Angus> But isn't... > > > > Angus> Hmmm, so you're suggesting a bunch of free functions which > > Angus> provide a world-visble interface to class LyX's member > > Angus> variables, this class itself being hidden away in the .C > > file. > > > > But class LyX's member variables are just a bunch of global > > variables hidden in a `singleton class' just for the sake of using a > > buzzword, aren't they? > > > > Seriously, I do not understand what is the purpose of a singleton > > class versus global variables hidden in some namespace. > > The order of destruction of static variables is undefined. If they > are encapsulated inside a class then this order is defined --- by us. Statics in a single file will be destructed in last-to-first order. > However, I don't think that any of this is really anything more than > aesthetics. I _may_ go down this route, but I'm much more interested > in > * finish off InsetExternal, > * think about killing off InsetGraphics > * think about moving the LaTeX part of InsetInclude into InsetExternal > * think about a FileName class that can handle environment variables > * clean up InsetBibtex > * creating a BiblioCache analogous to GraphicsCache, stripping out > all our home made citation stuff and using BibTeX to do the hard work. > > Oh, and before I get carried away, I should finish off the Controller > cleanup... So do that and I take care of this namespace business. Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz <[EMAIL PROTECTED]> writes: | Statics in a single file will be destructed in last-to-first order. One problem is still that several of the global varialbes cannot be static, they need more information before they can be initialized. That is easily solved with a class. Also pre-main construction of complex objects often have problems. -- Lgb
Re: A singleton LyX class, 1st steps
Lars Gullik Bjønnes wrote:
>>> I can see it is possible. Why is it 'preferable'?
>>
> | Free functions provide (often...) better encapsulation (Scott
> | Meyers?).
>
> Btu not if they operatoe on global variables... then you do not gain
> anything.
Where do you stand on the particular design under discussion?
We're talking about free functions that provide access to a class's
member variables. The class declaration, definition and single
instance is hidden entirely inside a .C file. Whether it is a
singleton class or not is nothing but an implementation detail.
namespace lyx {
namespace global {
/** start the whole thing off, instantiating the
* class variable that will store lastfiles,
* lyxrc, converters, formats
*
void exec(int argc, char * argv[]);
LastFiles & lastfiles();
LyXRC const & lyxrc();
Converters const & converters();
Formats const & formats();
} // namespace global
} // namespace lyx
Is this a 'good design'? One downer --- it is impossible to provide
const reference and reference accessor functions with the same name.
--
Angus
Re: A singleton LyX class, 1st steps
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Statics in a single file will be destructed in last-to-first
> | order.
>
> One problem is still that several of the global varialbes cannot be
> static, they need more information before they can be initialized.
> That is easily solved with a class.
Or by an accessor function:
boost::scoped_ptr controllers_;
Controllers const & controllers() {
if (!controllers_.get())
controllers_.reset(new Controllers);
return *controllers_.get();
}
--
Angus
Re: A singleton LyX class, 1st steps
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: I can see it is possible. Why is it 'preferable'? >>> >> | Free functions provide (often...) better encapsulation (Scott >> | Meyers?). >> >> Btu not if they operatoe on global variables... then you do not gain >> anything. > | Where do you stand on the particular design under discussion? > | We're talking about free functions that provide access to a class's | member variables. Free functions should ideally not access class variables, the functions should be free only when they don't need access to the class variables and only need the class's public interface for implementation. (and then of course no class variables should be public.) This is the encapsulation part. (or course this can be simulated with anon namespaces, but then the design is more "open" and access to the variables are not as controlled.) So, I guess, all in all I am more in favor of class variables than variables in a anon namespace. -- Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote:
> Free functions should ideally not access class variables,
This assumes that the class is not a random collection of individual
thing - which it is in our case - but "something real".
> the functions should be free only when they don't need access to the
> class variables and only need the class's public interface for
> implementation. (and then of course no class variables should be
> public.)
> This is the encapsulation part. (or course this can be simulated with
> anon namespaces, but then the design is more "open" and access to the
> variables are not as controlled.)
Handing out non-const refs to members is completely destroying the type
of encapsulation you speak of here ("access").
The two things are functionality-wise completely equivalent.
But: In the class solution you have to show private members like
'last_files_' in the .h, whereas in the namespace solution they are
hidden in the .C. So this is better encapsulation of the "visibility"
type.
> So, I guess, all in all I am more in favor of class variables than
> variables in a anon namespace.
Which is a bit of a surprise to me.
We have a draw when it comes to encapsulating access and a point for
namespaces when it comes to not exposing implementation details.
Well. So let's stay with the class as it is.
I am not religious about this bit.
Andre'
Re: A singleton LyX class, 1st steps
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> However, I don't think that any of this is really anything more Angus> than aesthetics. I _may_ go down this route, but I'm much more Angus> interested in [...] Of course :) JMarc
Re: A singleton LyX class, 1st steps
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote:
>> Free functions should ideally not access class variables,
>
| This assumes that the class is not a random collection of individual
| thing - which it is in our case - but "something real".
then perhaps each of them should be its own singleton?
>> the functions should be free only when they don't need access to the
>> class variables and only need the class's public interface for
>> implementation. (and then of course no class variables should be
>> public.)
>
>> This is the encapsulation part. (or course this can be simulated with
>> anon namespaces, but then the design is more "open" and access to the
>> variables are not as controlled.)
>
| Handing out non-const refs to members is completely destroying the type
| of encapsulation you speak of here ("access").
Only in part.
>
| The two things are functionality-wise completely equivalent.
>
| But: In the class solution you have to show private members like
| 'last_files_' in the .h, whereas in the namespace solution they are
| hidden in the .C. So this is better encapsulation of the "visibility"
| type.
The class solution for this is pimpl.
--
Lgb
Re: A singleton LyX class, 1st steps
On Wed, Oct 15, 2003 at 03:03:06PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote:
> >> Free functions should ideally not access class variables,
> >
> | This assumes that the class is not a random collection of individual
> | thing - which it is in our case - but "something real".
>
> then perhaps each of them should be its own singleton?
Or a static variable in a namespace.
*eg*
> >> the functions should be free only when they don't need access to the
> >> class variables and only need the class's public interface for
> >> implementation. (and then of course no class variables should be
> >> public.)
> >
> >> This is the encapsulation part. (or course this can be simulated with
> >> anon namespaces, but then the design is more "open" and access to the
> >> variables are not as controlled.)
> >
> | Handing out non-const refs to members is completely destroying the type
> | of encapsulation you speak of here ("access").
>
> Only in part.
It is _exactly_ the same whether I have a reference to a member of a
singleton or whether I have a reference to some static variable in some
namespace. There is not a wee bit more encapsulation on the class side.
> | The two things are functionality-wise completely equivalent.
>
> >
> | But: In the class solution you have to show private members like
> | 'last_files_' in the .h, whereas in the namespace solution they are
> | hidden in the .C. So this is better encapsulation of the "visibility"
> | type.
>
> The class solution for this is pimpl.
I have been waiting for this one.
We'd better stop now.
Andre'
Re: A singleton LyX class, 1st steps
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Oct 15, 2003 at 03:03:06PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Wed, Oct 15, 2003 at 01:52:31PM +0200, Lars Gullik Bjønnes wrote:
>> >> Free functions should ideally not access class variables,
>> >
>> | This assumes that the class is not a random collection of individual
>> | thing - which it is in our case - but "something real".
>>
>> then perhaps each of them should be its own singleton?
>
| Or a static variable in a namespace.
What would be the point in that?
we don't use static variables in file scope, we use anon namespaces
there.
>> | Handing out non-const refs to members is completely destroying the type
>> | of encapsulation you speak of here ("access").
>>
>> Only in part.
>
| It is _exactly_ the same whether I have a reference to a member of a
| singleton or whether I have a reference to some static variable in some
| namespace. There is not a wee bit more encapsulation on the class side.
except that you can modify/controll access to variables with
accessors.
>> The class solution for this is pimpl.
>
| I have been waiting for this one.
>
| We'd better stop now.
ok with me.
--
Lgb
