Hi Bob,

[Couldn't resist jumping into this topic :)]

Even if you look at traditional unix (or similar) kernel internals,
although they tend to use functional paradigms, they do have a
OOP-like flavor. Example:

Everything in a unix system is a 'file' (well not really with
networking logic, but it is one of the most important abstractions).
There is a notion of a 'abstract' base class 'file', and then there
are different 'types' of files - regular, directory, devices etc... So
you 'instantiate' a specific 'concrete' object when dealing with a
specific file. What are the methods that apply to all files? There is
open(), close(), read(), write(), ioctl() etc...  Not all methods are
valid for certain kinds of files - e.g. usually you don't write() to a
keyboard device.

In unix and C, the OOP is modeled using structs (to store various
attributes, or data members), and each struct tends to have
'pointer-to-functions' (listed above in case of files) to actual
implementation on how to deal with such objects in the system.

In fact the device-driver framework in unix can be thought of as an
excellent example of polymorphism where a table stores all the
specific functions that operate on the device.

Grouping data and its associated operations is one of the hallmarks of
OOP. In C, there is no *direct* support to express such groupings
where as in C++ (and other OOP languages), there is direct support via
notion of 'classes'  to express such relationships.

I would recommend this book: 'The design and evolution of C++' by
Bjarne Stroustrup where such topics are discussed more in depth.

Hope this helps.


On Wed, Jan 20, 2010 at 8:31 AM, Bob McConnell <r...@cbord.com> wrote:
> From: tedd
>> At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>>> Some problems will fit into it, some don't.
>> I teach OOP thinking at the local college and haven't run into a
>> problem that doesn't fit. For example, in my last class I had a woman
>> who wanted to pick out a blue dress for her upcoming wedding
>> anniversary. The class worked out the problem with a OOP solution.
> Hi Tedd,
> Here's one you can think about. I have a box, purchased off the shelf,
> with multiple serial ports and an Ethernet port. It contains a 68EN383
> CPU with expandable flash and RAM. The firmware includes a simple driver
> application to create extended serial ports for MS-Windows, but allows
> it to be replaced with a custom application. The included SDK consists
> of the gcc cross-compiler and libraries with a Xinu kernel and default
> drivers for a variety of standard protocols.
> I need to build a communications node replacing the default drivers with
> custom handlers for a variety of devices. It must connect to a server
> which will send it configuration messages telling it what hardware and
> protocols will be connected to each port. The Xinu package includes
> Posix threads.
> In the past 23 years I have solved this problem six times with five
> different pieces of hardware. But I still don't see how to apply OOP to
> it.
>> ----
>>> Some people can look at problems and see objects and some can't.
>> That's for certain -- but in time just about everyone can understand
>> the basic concepts of OOP.
> Understanding basic concepts and understanding how to map them on to
> real problems are two entirely different skill sets. I understand the
> concepts, they just don't make any sense to me. All of the definitions
> are backwards from the way I learned to evaluate problems. I feel like a
> carpenter trying to figure out how to use a plumber's toolbox. There are
> some things in there I think I recognize, but most of it is entirely
> foreign to me.
> Cheers,
> Bob McConnell
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to