On Thu, Feb 23, 2012 at 03:58:13PM -0700, msib...@crosswire.com wrote: > SNIP [I really don't like biting for what is an obvious flamewar, but sometimes there's useful bits of fallacy which need busting through, so I'll be picking those up and side-stepping the bait.]
> FVWM is not more portable than it would be if it was Object Oriented. > FVWM is not more extensible than it would be if it was OO. > FVWM does not integrate as easily with third party code, as it would if > it was OO. Unfortunately, you're under the impression that the language -- and more specifically -- the *paradigm* is the most important aspect of any program. But this is not true at all. Take houses for instance. Are you going to argue that despite an igloo and a log cabin being different houses, that we should all live inside caravans, simply because a caravan is a home with wheels? Igloos and log cabins are what they are, but a caravan has no advantage over the others, *unless* you want to travel with your home. But then that's a completely different concept (procedural versus OO), but has nothing to do with them being related (that they're all types of home). I might choose an igloo over a log cabin or vice-versa, but that's my choice. The only limitation in there is if I suddenly decide I need to travel with my home, but then it becomes a different problem. So by your suggesting we somehow need to change languages because of some limitation is nonsense; that we might want to switch languages because you *personally* see a benefit in it is equally nonsense. These sorts of arguments always are, because no one ever is able to justify personal preference. FVWM is written in C, and that's just the way it is. There are no drawbacks to this approach. It's a damn *good* one, because guess what the other interfaces are written in, and *were* written in to begin with? That's right: C. You use words such as 'extensible', and 'portable' as if you have an idea of what they mean in the context of FVWM as it is now. You also go as far as to mention 'third party code'. Do you not realise we have all of that right now with FVWM's module interface, including language-bindings in Perl (and to a lesser-extent sh)? That you might not like the choice of bindings is entirely irrelevant. But the point is, they're there. Just how would an OO approach (note that I don't mention C++ here -- I care not for the language) make this any more or less extensible? The interface between FVWM and its modules is not exposed to someone wanting to do this -- that's the whole point of abstraction. If I were to tell you that it was written in C++ behind the scenes it wouldn't make any difference to your making this more extensible. > Regarding database integration, pretty much every *nix programming > environment has existing libs for integrating with sqlite, no pipelining > required. Ah. And now I remember you: http://www.mail-archive.com/fvwm@fvwm.org/msg01781.html Note that you're under another mistaken impression that sqlite specifically cures unknown problems for you (or worse yet you're stating some form of an XY problem). > My interest is not so much in the database, but in the fact that it > improves syntactical constraint, extensibility, and supportability in > one include statement. The same motives are behind using WxWidgets. Wx, Can you list here exactly, within the context of databases and FVWM, what the following words/phrases mean: syntactical constraint extensibility supportability Sqlite doesn't offer you anything over FVWM's mechanism of using *plain text*, other than a massive headache in terms of locking and concurrent access (by which I mean not just from users, but modules communicating with FVWM -- and last I checked concurrency and locking at that level wasn't supported). There's a reason why plain text works, by the way. And a database to store values solves nothing, it increases problems. > and Sqlite integration would reduce the rewrite time to version 1.0 by a > significant amount, and with decent design practices, if you still want > Xlib, go ahead. Just write an Xlib based widget object and include it as > a plugin or a module. Nothing prevents that. Careful here. Xlib has nothing to do with storing values (which sqlite does) -- so I am not sure what you're getting at here, other than not understanding how and why FVWM even needs to use Xlib. > Or in other words: > FVWM is not more hackable, than it would be if it used SQL as > configuration repository. So let's take your example. How would I remove a titlebar from a window, exactly? UPDATE table window SET properties.titlebar = 0 where properties.id = ?; Versus: WindowStyle !Title Hmm. No thanks. Now consider how this would work for more than one window where you'd need locking on the table -- and use transactions -- because there's a chance the window might die, or another window is mapped meaning this hypothetical window table would corrupt it -- and tell me why it's better? It's not. It's worse. > FVWM is not more syntactically stable, than it would be if it used > SQL... > FVWM is not more supportable, than it would be if it used SQL. Clearly, I've overlooked something as a developer of FVWM all this time if SQLite is going to solve all our problems when FVWM has no concept of a database. Enlightenment should realise the dangers of this, with their binary configurations file. Your database idea is just as bad, by the way. Corrupting plain text has a large chance of working, by the way. If you make syntax errors, FVWM can keep calm and carry on. If your database jimmies itself through problems of concurrency (ahem) what happens then? Bye-bye settings without *any* backup at all. And given how SQLite specifically likes to eschew compatibility between versions, *I* wouldn't want to be responsible for supporting multiple versions. You speak of third party operability -- tell me how this is a good thing? At least with plain text I can write (and have done with fvwm-convert-2.6 -- and I know Dan Espen has as well) a file to maintain compatibility. Happy days. > I have seen many times on this list, a prevelance of a bizarre attitude > that any programatic logic a third party should wish to integrate with > FVWM, should be done within the configuration of FVWM itself, and that > any other solution is bad. Have you? Point me towards your examples, and I'm sure I can justify each and every one of them. But then as I do so, please then expect me to ask you to outline how SQLite would help. > Yet FVWM's configuration syntax is incredibly intolerant of anyone who > isn't an old-school C programmer. It certainly isn't in the interest of We don't enforce a language-style at all in the config file, and we sure as hell don't make it look like C. You're muddling things here. You'll hear on the grape vine if you so wish to, a resurgence of people looking back towards the ideals of programs like FVWM which use more "simpler" means of configuration in comparison to the direction DEs like GNOME and Unity, where the perceived control and attitude of what the program will let you do is a somehow a new thing; a breath of fresh-air. I definitely want to maintain that, and a database is therefore out of the question. Not just for this reason, but given your absurd assertions for needing it, I'll take fresh-air as a good enough one for not needing it. :) By the way, you are *more* than free, using perllib to write a program in Perl using its DBD::SQLite bindings to do exactly what you want. And guess what? You can do all of this without a rewrite in C++, without thinking Xlib is somehow the wrong thing to be using, and ironically by doing that, you've just made FVWM extensible using its own mechanism to do what you want, and then disproving all your points above. That's why I like FVWM -- even more so now -- it's just beaten you at your own game. :) -- Thomas Adam
