in reply to Re^7: Your main event may be another's side-show.
in thread Your main event may be another's side-show.

Then should we also exclude ...

You (and all the others that sit behind your royal we), should not exclude anything that you individually or collectively find useful. I described my distaste for frameworks, and my reasons. It is up to anyone else to reach their own conclusions.

I can't. I've never used any of those. I've created my own :) But it does not mean that it is not possible.

Oh, it is possible to use event-driven logic within a threaded application. For example, Tk's event loop runs just fine within a thread(*). The same is true of Prima & Wx. And OpenGL. And Win32::GUI. And any event loop constructed around select, even when encapsulated and simplified through the use of IO::Select work fine in threads also.

(*)Though you do have to be careful not to try using tk objects across multiple threads.

So there is no fundamental incompatibility between threading and event-driven programming.

But--and this is the whole point--all of the above are libraries! Not frameworks. And it demonstrates exactly why I like the former and dislike the latter.

With libraries, I call whichever library best serves my needs, whenever I want, and in whatever combination I want.

With frameworks, I have to try and remotely manipulate them into calling me at the appropriate time to do whatever needs to be done, and they fall in a heap around my ears if I do something they don't like.

(Well written) Libraries good. Frameworks suck! (But each to their own:)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy
  • Comment on Re^8: Your main event may be another's side-show.

Replies are listed 'Best First'.
Re^9: Your main event may be another's side-show.
by andal (Hermit) on Oct 25, 2010 at 08:48 UTC
    But--and this is the whole point--all of the above are libraries! Not frameworks

    Well. I guess we (I mean you and I) have different understanding on what a framework is. I would consider the Tk's event loop a part of "framework". But you consider it a "library" :)

    Since the subject resulted in just personal dislike of certain modules from CPAN, then I don't see any reason to argue about this. I'm trying to respect personal dislikes :)

[reply]
      I guess we (I mean you and I) have different understanding on what a framework is.

      The best online definition I could find of a framework in this context is at http://parlab.eecs.berkeley.edu/wiki/patterns/glossary which is fairly authoratative:

      Framework: A framework is a software environment organized around a software architecture that allows for programmer customizations only in harmony with the software architecture

      Which mirrors the kind of crtisisms I've been levelling at them when I've said: They proscribe the entire architecture of your application; and: They prevent you from using all the tools in your toolbox.

      My own definition is a simple test. Do I call them; or do they call me? The former is a library, the latter a framework. (That line can be blurred.)

      I don't see any reason to argue about this. I'm trying to respect personal dislikes :)

      Agreed! One man's squishy, slimey, salty yuk, is another man's caviare :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations