Commit
…terface This allows manager::iteration to be made private in order to restrict access to handler iterators within the manager class and not outside it.
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,7 +41,7 @@ namespace game_events { | |
/// If a second manager object is created before destroying the previous | ||
/// one, the game will crash with an assertion failure. | ||
class manager { | ||
public: | ||
private: | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
Vultraz
Author
Member
|
||
/// This class is similar to an input iterator through event handlers, | ||
/// except each instance knows its own end (determined when constructed). | ||
/// Subsequent dereferences are not guaranteed to return the same element, | ||
|
@@ -92,7 +92,6 @@ namespace game_events { | |
game_data * gamedata_; | ||
}; | ||
|
||
private: | ||
// Performs an assertion check to ensure these members are not null. | ||
friend void event_handler::disable(); | ||
|
||
|
@@ -121,6 +120,9 @@ namespace game_events { | |
const std::string& type = std::string()); | ||
void write_events(config& cfg) const; | ||
|
||
using event_func_t = std::function<void(game_events::manager&, handler_ptr)>; | ||
void execute_on_events(const std::string& event_id, event_func_t func); | ||
|
||
game_events::wml_event_pump & pump(); | ||
|
||
game_events::wmi_manager& wml_menu_items() | ||
|
13 comments
on commit be665e2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tags @GregoryLundberg since relevant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GregoryLundberg ok, so looking at this further it looks like handler_list
iterators are restricted to the manager::iteration
class, which is now private to the manager. How should I go from here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should stop and put this aside until 1.14 is released.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. If we go forward with odd/test even/release, this should be a 1.15 or 1.17 milestone.
Don't want to break such a central function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.17 wat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it took 20 years to get the mess we have, it's not gonna get fixed in a year.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it damn well not take another 20.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain the mess fully, though. Looking at it it seems like the mess is rather localized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, one valid approach would be to create a new header for the feature which is JUST for the feature, remove it from the original headers and chance down all the places which break (a lot will but most will be fixable by removing an unneeded reference).
I fear it's a Rabbit Hole, though. And a Gordian Knot.
As I recall when I was pulling it out, last Autumn, I found the feature spread through two or three headers which pulled in a lot of unrelated stuff and were referenced all over the place by a huge number of totally unrelated things.
What I did was a header and rough implementation and the goal was a clean compile which was usable but only included the header where it was absolutely needed. I remember compile after compile tracing down where to remove the unneeded references and fixing the sudden lack of things which were totally unrelated, came along for the ride, and broke something when suddenly missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you really must continue working on this, start a branch and don't merge it until after 1.14 is branched off (and then only if it works, of course).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Second,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admittedly, there is much to be done. However, I'm only looking at the handler_list
and smart_list
classes right now and how the former can be simplified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Do it on a branch.
Could just delete the line as
private
is the default access level for classes.