Menu
▾
▴
sooc-devel
|
From: Mike R. <mik...@gm...> - 2007-08-20 00:50:20
|
I've invested rather a lot of time into this project. Certainly it accounts for the vast majority of my coding time over the past year or more. The base system of Sooc is more powerful than ever, and the accompanying class library is steadily improving. But now I'm wondering, as I have on occasion before, whether Sooc is a productive endeavor. I thought of a real test of Sooc's usefulness. We could rest assured that it is a Good Thing if we (or I) port a C++ or Java project to Sooc and the result is more manageable code. If the code just grows uglier or more confusing, it is a pretty safe bet that Sooc is only valuable as an exercise in OOP. I don't propose halting development. In fact, I have a few important ideas about the collections module that really should be implemented. Nonetheless, I want to start working in parallel on a port of some existing code as soon as possible. Any thoughts? Ideas as to which code to port would be especially handy. -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-20 03:52:00
|
Are you talking about code from a "real," third-party project or something that you or I have worked on? Aside from that, I believe I have told you before that I have always thought that some sort of official sample program should be part of the overall Sooc project. Such a program would be useful in order to demonstrate the structure of a Sooc program as well as the usefulness of the library in general. Consequently, I am all for your idea. I think, ideally, at some point, we should have a program written in several different languages, such as C/Sooc, C++, Java, and Objective-C. One might even consider throwing traditional C or C/Glib in there (you know, just for fun). But the idea would be to provide a reasonable comparison across programming techniques. On 8/19/07, Mike Richman <mik...@gm...> wrote: > > I've invested rather a lot of time into this project. Certainly it > accounts for the vast majority of my coding time over the past year or > more. The base system of Sooc is more powerful than ever, and the > accompanying class library is steadily improving. But now I'm > wondering, as I have on occasion before, whether Sooc is a productive > endeavor. > > I thought of a real test of Sooc's usefulness. We could rest assured > that it is a Good Thing if we (or I) port a C++ or Java project to > Sooc and the result is more manageable code. If the code just grows > uglier or more confusing, it is a pretty safe bet that Sooc is only > valuable as an exercise in OOP. > > I don't propose halting development. In fact, I have a few important > ideas about the collections module that really should be implemented. > Nonetheless, I want to start working in parallel on a port of some > existing code as soon as possible. > > Any thoughts? Ideas as to which code to port would be especially handy. > > -Mike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-20 11:29:55
|
I'm talking about a third-party project. The reason is simple enough: Sooc was designed with our, and especially my, needs in mind. Now we need to see how it applies to others' design. |
|
From: Dan R. <sta...@gm...> - 2007-08-20 21:10:22
|
Mike, Your reasoning here makes a lot of sense. While I still propose following my aforementioned exercise at some point as a sort of post mortem, we definitely do need to see how Sooc stacks up to external needs. I imagine we need to select some kind of console-based utility to port. At the moment, however, nothing is really coming to mind. But I will think about it and get back to you if I have any ideas. --Dan On 8/20/07, Mike Richman <mik...@gm...> wrote: > > I'm talking about a third-party project. The reason is simple enough: > Sooc was designed with our, and especially my, needs in mind. Now we > need to see how it applies to others' design. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-20 22:27:55
|
I don't know that it has to be a console utility. We should really just be looking for something reasonably small writtenin C++ or Java. If a GUI is involved, we can port it to GTK+. I know this would complicate the comparison of Sooc with the other object systems, but Sooc needs to be proven to work well with GTK+ to be practical anyway. There's nothing wrong with learning a little Swing, gtkmm, Qt, networking, image handling, or any other random thing on the fly, I don't think. This is especially true if we focus primarily on porting the object system itself and only worry about the underlying algorithms in the original code if we need to change it. So... what small utilities do we (I?) like and would we (I?) be interested in porting? I'll be thinking about it; let me know if you come up with anything. -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-20 22:40:03
|
Doesn't gtk+ use GObject? I thought maybe that porting a GUI app that uses the GObject hierarchy would make the Sooc object system less obvious. Or at least it would add complication to this test. On 8/20/07, Mike Richman <mik...@gm...> wrote: > > I don't know that it has to be a console utility. We should really > just be looking for something reasonably small writtenin C++ or Java. > If a GUI is involved, we can port it to GTK+. I know this would > complicate the comparison of Sooc with the other object systems, but > Sooc needs to be proven to work well with GTK+ to be practical anyway. > There's nothing wrong with learning a little Swing, gtkmm, Qt, > networking, image handling, or any other random thing on the fly, I > don't think. This is especially true if we focus primarily on porting > the object system itself and only worry about the underlying > algorithms in the original code if we need to change it. > > So... what small utilities do we (I?) like and would we (I?) be > interested in porting? I'll be thinking about it; let me know if you > come up with anything. > > -Mike > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-21 04:38:46
|
If we port a gtkmm project, we will have to work with GObject to an extent. In particular, a C++ project is likely to include derived widgets. Those are a major pain with GtkWidget. But with Sooc, they can be expressed using a combination of composition and inheritance, which I did easily enough in OTweeze. The SGtkWidget wrapper for GtkWidget was designed in like 5 minutes and it was straightforward enough to use. In fact, it's because this is exactly the sort of challenge Sooc needs to handle gracefully that I think a gtkmm project would be appropriate. Also, the gtkmm website maintains a list of some client projects, which might be a good starting point in choosing a project. That said, a completely different project might be still more appropriate. I'll be thinking about C++ and Java apps I know of... or maybe we can just find something on SF somewhere :) -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-21 20:23:47
|
Okay, that sounds reasonable enough. On 8/21/07, Mike Richman <mik...@gm...> wrote: > > If we port a gtkmm project, we will have to work with GObject to an > extent. In particular, a C++ project is likely to include derived > widgets. Those are a major pain with GtkWidget. But with Sooc, they > can be expressed using a combination of composition and inheritance, > which I did easily enough in OTweeze. The SGtkWidget wrapper for > GtkWidget was designed in like 5 minutes and it was straightforward > enough to use. In fact, it's because this is exactly the sort of > challenge Sooc needs to handle gracefully that I think a gtkmm project > would be appropriate. Also, the gtkmm website maintains a list of > some client projects, which might be a good starting point in choosing > a project. > > That said, a completely different project might be still more > appropriate. I'll be thinking about C++ and Java apps I know of... or > maybe we can just find something on SF somewhere :) > > -Mike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X