Gammon Forum : MUSHclient : Development : Current plugin scoping

Entire forum ➜ MUSHclient ➜ Development ➜ Current plugin scoping

Current plugin scoping

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #30 on Wed 15 Sep 2010 10:35 PM (UTC)

Amended on Wed 15 Sep 2010 10:37 PM (UTC) by Twisol

Message

David Haley said:

Twisol:

Nick Gammon said:
Now if you rewrite the whole way it is done, with some sort of "apply function f to all plugins" then you expect stuff like the current plugin to be saved/restored by the auto-apply stuff, and you aren't confused any more.

This is exactly why the loop issue isn't "orthogonal". (I think you overuse that word a bit, btw. :P)

My informal definition of "orthogonal": wholly separate tasks. I see it as (1) saving the plugin and resetting it later, and (2) doing something with the current plugin. Of course, now that I understand your suggested solution, I see that it makes sense. But the loop construct will still have to solve (1) in its own way anyways. Since it's only in one or two places, it could use an explicit try/catch, even though that'll duplicate the resetting code. Or it could use my CurrentPluginScoper. The issues are orthogonal; it's how you put them together that solves the particular problem.

[EDIT] In cases that don't need looping, an explicit scoper could be used, or a dedicated function could be created that takes a functor/function pointer just like the iterating version. The power of orthogonality is that the pieces can be used separately. :D

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by Nick Gammon Australia (23,046 posts) Bio Forum Administrator

Date Reply #31 on Wed 15 Sep 2010 10:38 PM (UTC)

Message

Twisol said:

So we'd actually write that apply method (i.e. DoForEachPlugin)? I had assumed you and David were talking about std::for_each.

The for_each function isn't particularly complex. It looks like this:


template <class ITER, class F> inline
F for_each (ITER first, ITER last, F func)
  {
  for ( ; first != last; ++first)
    func (*first);
  return func;
  }

And as noted by Josuttis (http://www.josuttis.com/libbook/) the standard implementation doesn't handle the case of func deleting an item (ie. an item deleting itself).

The safe_for_each in the MUSHclient source does handle that:


template <class ITER, class F> inline
F safe_for_each (ITER first, ITER last, F func)
  {
  while (first != last)
    func (*first++);
  return func;
  }

However this itself raises an interesting point. If you are going to write DoForEachPlugin you need to account for whether not the function you pass to DoForEachPlugin might change the list (eg. delete a plugin, or change its sequence). It may not have occurred to you initially to even consider that issue (conceivably the current code doesn't either).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #32 on Wed 15 Sep 2010 10:40 PM (UTC)

Message

Well, "initially" I hadn't even considered looping at all, preferring to tackle the singular issue of ensuring that the plugin is always reset even in the face of exceptions.

I understand that it's not complex, it just didn't occur to me. :)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

85,271 views.

This is page 3, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top