From: Michael H. <mic...@el...> - 2005-08-30 07:15:13
|
Guys, I have finished modifying files for now, hope everything still works. (It does for me.) Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 07:26:16
|
Michael, MH> I have finished modifying files for now, hope everything still works. MH> (It does for me.) Same here. Well done. Just a glitch: I'm not sure that Visitor.h, with all its metadata includes, belongs in core. But I have a pending analysis to do on that one. Some time ago Milan has kindly explained to me why it needs to be so, but I have to think about it some more. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <mi...@km...> - 2005-09-01 08:02:20
|
Nando, Nando Dessena wrote: > Just a glitch: I'm not sure that Visitor.h, with all its metadata > includes, belongs in core. But I have a pending analysis to do on that > one. Some time ago Milan has kindly explained to me why it needs to be > so, but I have to think about it some more. How about creating a special folder called "visitor" and put: - Visitor.cpp - Visitor.h - contextmenuvisitor.cpp/h + all other visitor classes created in future in it? -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-09-01 18:36:29
|
Milan, M> How about creating a special folder called "visitor" and put: M> - Visitor.cpp M> - Visitor.h M> - contextmenuvisitor.cpp/h M> + all other visitor classes created in future M> in it? Mmm, I'd rather separate classes by area than by genealogy. Otherwise we should put all subjects in a folder, all observers in another, all exceptions... you get the idea. I have solved my doubts in the meantime. Have a look at the current structure in CVS. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <mi...@km...> - 2005-09-02 05:36:15
|
Nando Dessena wrote: > M> How about creating a special folder called "visitor" and put: > > M> - Visitor.cpp > M> - Visitor.h > M> - contextmenuvisitor.cpp/h > M> + all other visitor classes created in future > > M> in it? > > Mmm, I'd rather separate classes by area than by genealogy. Otherwise > we should put all subjects in a folder, all observers in another, all > exceptions... you get the idea. Yes. > I have solved my doubts in the meantime. Have a look at the current > structure in CVS. Ok, I'm fine with that. -- Milan Babuskov http://abrick.sourceforge.net |
From: Milan B. <albis@EUnet.yu> - 2005-08-30 13:44:42
|
Nando Dessena wrote: > Just a glitch: I'm not sure that Visitor.h, with all its metadata > includes, belongs in core. But I have a pending analysis to do on that > one. Some time ago Milan has kindly explained to me why it needs to be > so, but I have to think about it some more. Well, it doesn't have to include them, but let me quote Gregory's comment in code: // It is possible to use forward declaration here // but then you will have to include this files in each // <concrete_visitor>.cpp (or .h) file -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-08-30 17:14:46
|
Milan, >> Just a glitch: I'm not sure that Visitor.h, with all its metadata >> includes, belongs in core. But I have a pending analysis to do on that >> one. Some time ago Milan has kindly explained to me why it needs to be >> so, but I have to think about it some more. M> Well, it doesn't have to include them, but let me quote Gregory's M> comment in code: M> // It is possible to use forward declaration here M> // but then you will have to include this files in each M> // <concrete_visitor>.cpp (or .h) file Yep. My concern is not about how Visitor.h depends on the concrete visited objects (through includes or through forward declarations), but why. Adding a type of visited object shouldn't require changing the visitor abstract interface, I guess, so I have taken note to look into it to try and understand it more; when I have refreshed my memory about the visitor pattern, I'll speak up again. Ciao -- Nando Dessena http://www.flamerobin.org |