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
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 ra
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
> "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
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 th
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
>> anythin
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
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 unde
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
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' *
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
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 su
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 suggesti
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 suggesti
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-
> "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 w
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 aw
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();
>
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 ex
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
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):
> + las
> "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 (MenuWr
This moves the lastfiles global variable into LyX and makes
emergencyCleanup a non-static member function.
Comments?
--
AngusIndex: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retr
23 matches
Mail list logo