Certainly, there are two ways of using OOP systems (and these can be blended to any degree).
One way is to only reuse the objects which are provided with the system. This is simple and dependable. While this IS reuse, it does not deliver on the OOP promise. Each programmer or group still does each function or task in their own code, while other programmers or groups repeat the same tasks, probably in different ways.
The other way is much more complicated. You have to design an OOP paradigm for the application or system you are implementing and build an extension of the OOP system. It is only when you do this that you reap the major promised benefits of OOP, that your application or system will be reusable and much more easily maintained. Every programmer or group must be committed to the use of the common code base for common tasks. It is more complicated (and political) because everyone must agree in the design stage how everything is to be done. If they are diligent in the design (and, to some extent, lucky) they will produce a system where most objects are reused in many ways. The system is modular, the interfaces are consistent, and changes are highly maintainable as long as the overarching design is adhered to.
I have been involved in both types of OOP projects. Mainly due to politics, I think, the simple but unfulfilling way is much more common.
I totally agree that VisualWorks is an awesome cross-platform development tool. I used to work with it at BellSouth. You could develop/compile an app on WinNT and copy the resulting binary to HP-UX. It would run there with no changes, no problems, and exactly the same GUI interface.
Also, we could develop on WinNT with a Windows, a Mac or an X-Windows interface.
And all of this was in 1995, when it was a Parc Place product. I assume it has improved in the past five years.
The article is right on the money
on
Why Not MySQL?
·
· Score: 1
The Jagannath article is totally correct. Look at it this way: lots of us are deeply critical of Microsoft and a great deal of our criticsm revolves around their provision of applications such as Access that appear to the casual user to be high-quality products, but in reality cut so many corners that they are unfit for any meaningful task. For example, workgroups (or even larger organizations) try to create multiuser, networked applications in Access and they usually fail miserably due to the lack of the necessary underlying features for implementing such a project.
It is much the same with MySQL. The article does not merely make vague, general criticsms but starts by explaining the basic features required of a true DBMS, then shows how MySQL either does not attempt to support them or, even worse, claims to support some of them but does not do a thorough, adequate implementation.
In the end, it is your data. If you want to sacrifice speed for reliability and integrity, go for it.
Electronic manuals are great when you need to look up something very specific. They allow you to quickly (sometimes) search for relevant references and cross-link related topics.
However, to thoroughly peruse manuals and user guides, printed documents are a necessity. Reading a computer screen for anything more than a few minutes at a time is a strain on both the eyes and the muscles (for me, especially the neck muscles).
So, I say that both forms of documentation have their purposes. I.e., printed documentation should not be eliminated.
This was rated "Funny", but it was actually the first thing I thought of when I considered this topic. I, too, often use the "wasted" time in the bathroom reading manuals or user guides that I otherwise don't have time for.
With Oracle 8.0 and higher, plus the partitioning option, a single table can be stored in multiple tablespaces and/or datafiles. I am sure that this feature can be used to exceed the 2GB filesize limit.
However, it introduces other management problems. Once you have created a table so large, you would no longer be able to create a single-file export of the table. You can, however, export each partition, separately, so I guess everything would be okay.
Slashdot Mirror
Uh, excuse me, haven't you heard? The developer resource pool IS sparse.
Certainly, there are two ways of using OOP systems (and these can be blended to any degree).
One way is to only reuse the objects which are provided with the system. This is simple and dependable. While this IS reuse, it does not deliver on the OOP promise. Each programmer or group still does each function or task in their own code, while other programmers or groups repeat the same tasks, probably in different ways.
The other way is much more complicated. You have to design an OOP paradigm for the application or system you are implementing and build an extension of the OOP system. It is only when you do this that you reap the major promised benefits of OOP, that your application or system will be reusable and much more easily maintained. Every programmer or group must be committed to the use of the common code base for common tasks. It is more complicated (and political) because everyone must agree in the design stage how everything is to be done. If they are diligent in the design (and, to some extent, lucky) they will produce a system where most objects are reused in many ways. The system is modular, the interfaces are consistent, and changes are highly maintainable as long as the overarching design is adhered to.
I have been involved in both types of OOP projects. Mainly due to politics, I think, the simple but unfulfilling way is much more common.
I totally agree that VisualWorks is an awesome cross-platform development tool. I used to work with it at BellSouth. You could develop/compile an app on WinNT and copy the resulting binary to HP-UX. It would run there with no changes, no problems, and exactly the same GUI interface.
Also, we could develop on WinNT with a Windows, a Mac or an X-Windows interface.
And all of this was in 1995, when it was a Parc Place product. I assume it has improved in the past five years.
The Jagannath article is totally correct. Look at it this way: lots of us are deeply critical of Microsoft and a great deal of our criticsm revolves around their provision of applications such as Access that appear to the casual user to be high-quality products, but in reality cut so many corners that they are unfit for any meaningful task. For example, workgroups (or even larger organizations) try to create multiuser, networked applications in Access and they usually fail miserably due to the lack of the necessary underlying features for implementing such a project.
It is much the same with MySQL. The article does not merely make vague, general criticsms but starts by explaining the basic features required of a true DBMS, then shows how MySQL either does not attempt to support them or, even worse, claims to support some of them but does not do a thorough, adequate implementation.
In the end, it is your data. If you want to sacrifice speed for reliability and integrity, go for it.
Electronic manuals are great when you need to look up something very specific. They allow you to quickly (sometimes) search for relevant references and cross-link related topics.
However, to thoroughly peruse manuals and user guides, printed documents are a necessity. Reading a computer screen for anything more than a few minutes at a time is a strain on both the eyes and the muscles (for me, especially the neck muscles).
So, I say that both forms of documentation have their purposes. I.e., printed documentation should not be eliminated.
This was rated "Funny", but it was actually the first thing I thought of when I considered this topic. I, too, often use the "wasted" time in the bathroom reading manuals or user guides that I otherwise don't have time for.
Jason,
Is this something anybody can get, or just you?
Thanks,
Tim
With Oracle 8.0 and higher, plus the partitioning option, a single table can be stored in multiple tablespaces and/or datafiles. I am sure that this feature can be used to exceed the 2GB filesize limit.
However, it introduces other management problems. Once you have created a table so large, you would no longer be able to create a single-file export of the table. You can, however, export each partition, separately, so I guess everything would be okay.
Okay, I am a newbie, here. What exactly is a slashbox and where do I find them?
TIA,
Tim