clipka <nomail@nomail> wrote:
> *Now* you're talking about something OOP- and programming-related:
> Modularization. But what on earth does your previous post's talk of "concepts",
> pens, cars, dogs and cats have to do with this?

  In object-oriented programming a class is basically a user-defined type,
and a user-defined type is a concept. For example, "a string" is a concept,
and a string class is the implementation of that concept.

  A concept is basically something which behaves in a certain way. By writing
a class you are defining how it behaves.

  Inheritance is related to a hierarchy of concepts: More concrete concepts
inherit from more abstract concepts. For example, a file input stream may
inherit from a more generic input stream, both of which are concepts.

  The animal-dog example is not at all far-fetched. If you were to write
some kind of life simulation program with different plants and animals,
the classical inheritance hierarchy would, in fact, be basically perfect
for designing all the entities in that program.

> >   One of the most basic methods for keeping a large program manageable is
> > to subdivide it into smaller parts, hierarchically. When you write something
> > inside the large program, you shouldn't have to be keeping in mind the
> > *entire* program in order to be able to write that small part. You should
> > be able to keep in mind only the *relevant* parts of the rest of the program
> > necessary to make that small part work.

> BTW, note how the blurb may help to confuse: You're now talking about modular
> hierarchies (going back to cats, they're comprised of a body, a head, for legs
> and a tail); in your previous post, you were talking about conceptual
> hierarchies (cats and dogs both being animals).

  I don't see how those are mutually exclusive. A dog may be composed of
several parts, and a dog may be an animal, both at the same time. I really
don't see the problem.

  (In fact, inheritance and composition are two concepts of OOP.)

> You *need* the modular hierarchies for large projects; but the blurb focuses on
> the conceptual hierarchies.

  In many programs inheritance is best used to describe conceptual hierarchies.
It may not be about dogs and cats, but it may be eg. about file or socket
handles, strings, database entries, or basically anything. The mechanics
are still the same.

> >   The solution presented (although not originally invented) by object
> > orientedness to this problem is the concept of modules: Modules can have
> > both functionality and data, and they enclose both in a way that makes
> > managing the data easier in a large project. Modules can also form a
> > hierarchy (so modules can define sub-modules inside them, or own instances
> > of other modules, etc).

> Note that encapsulation in OO goes a step beyond what would typically be
> considered modularization: A module is typically thought of as a collection of
> code, typically coming with various data structures and a bit of module-global
> data as an aside, and a project would typically have one instance of each
> module. In OO, the focus is more on the data and the interface, with the code
> taking on the role of an aside, and the whole project would be dealing with
> multiple instances at once.

  Modular programming does know the concept of instantiating modules. For
example the modula programming language (which is not an OOP language) has
modules with public and private interfaces, and which can be instantiated
and referenced. (What makes it non-OOP is that it doesn't support inheritance
nor obviously dynamic binding.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> As I said, lots of kernels are written in FORTH (for small machines) or Ada 
> (for dangerous machines).

  I wonder why Ada never got much popularity, even though it was really
pushed at some point (especially by the US government, AFAIK). Was it
lack of compilers for common hardware or something?

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> How high is the influence of the most favorite programming languages on the
> further development hardware design?

Exactly. The Intel line of x86s was originally designed for Pascal. You can 
tell by looking at the four segments (which map exactly to Pascal data 
spaces) and the "ret n" instruction, even if there wasn't historical 
documentation backing it up.

> Maybe the latter is somewhat comforting. Not that the pure *existence* of
> dangerous machines would be.

I figure if you're writing any code that kills >100 people when it crashes, 
you probably shouldn't be writing it in a language that wasn't designed for 
that. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> As I said, lots of kernels are written in FORTH (for small machines) or Ada 
>> (for dangerous machines).
> 
>   I wonder why Ada never got much popularity, even though it was really
> pushed at some point (especially by the US government, AFAIK). Was it
> lack of compilers for common hardware or something?

Expense, I think. The GNU Ada compiler is currently the most featureful out 
there. But to call yourself Ada (at least for the first decade or so) you 
had to pay a fairly large sum to pass certification tests. You couldn't put 
something out there you'd thrown together, followed most but not all of the 
standard, and had compiler bugs you'd fix in the next release, and still 
market an Ada compiler.

Since things like compilers *are* things for which FOSS works great, that 
kind of put a big dent in Ada's adoption, I think. That and the FUD, of course.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Now, I ask again
>> tell me what Object Oriented Programming means.
> 
>   I have already written extensively about it in several posts in this
> thread.
> 

Sorry, I'm no wiser for reading them; But don't sweat it. :)

Post a reply to this message

On Thu, 23 Jul 2009 14:51:47 -0700, Darren New wrote:

> Expense, I think.

And performance, at least with the early compilers.  We had an IBM 
mainframe at my university that one student compiling Ada on would bring 
to its knees for hours.

Jim

Post a reply to this message

On 23-7-2009 2:58, David H. Burns wrote:
> andrel wrote:
>> On 22-7-2009 1:26, David H. Burns wrote:
>>> andrel wrote:
>>>
>>>> That you see your smiley does not mean everybody else will.
>>>
>>> Thanks. Did you see it? I did when I read my own post. I don't think 
>>> it shows up in the text in
>>> my "sent" file. These matters get complicated.
>>> :) (smiley ?)
>>>
>>
>> I do. In your post, not when replying :) , neither yours nor mine.
>> The point I tried to make earlier is that it depends on the mail 
>> reader of the person *reading*. You don't have an influence on it. You 
>> type a colon followed by a bracket, that is what you sent and what is 
>> supported by NNTP. After that somebody is trying to cleverly replace 
>> them by rotated smileys, which is OK as long as they get it right :/
>> IIRC they have problems with exotic ones like \o/ perhaps because they 
>> can conceivably be in a real post or in /ASCII art/.
>>
>> In short, there is a big chance that what you will see is not what I 
>> wrote. Perhaps it is what I intended.
> 
> Thanks, again, Andrel. The smileys work, :/ and \o/ came through as the 
> Ascii characters.

:/ might have been a smiley too, but isn't in TB. I remember having 
problems to understand the \o/ when I first met him, and am not 
surprised that TB doesn't replace it. I was expecting italics for /ASCII 
art/ but apparently that should have been /ASCII/ /art/. which is 
strange because *bold face* and _under line_ do range over the space.

> I'm using Thunderbird.

me too.

Post a reply to this message

On 07/23/09 11:15, David H. Burns wrote:
>> I'm sure you think in OOP all the time with POV-Ray. You create a
>> sphere. It's an object with certain properties (texture, location,
>> etc). Now let's say you want to rotate the sphere, does it hurt so
>> much to do something like:
>>
>> mysphere.rotate(45)
>>
>
> No! I think in terms of objects, not of OOP. The concept of an "object"
> as used
> in Pov-Ray in a valuable tool for thinking and programming -and used
> well there.
> What I have seen of OOP programming is something else. :)
>
> David
>

	OK. I have no idea what you're saying.

	What is the "No" referring to? Are you saying "no, it doesn't hurt"? 
Are you saying "No, I hate that way of doing it"? Are you sweeping your 
hand across my whole message and saying "No! I can't stand it!"?



-- 
Thesaurus: prehistoric reptile with a great vocabulary.

Post a reply to this message

On 07/23/09 13:12, David H. Burns wrote:
>> You clearly don't understand what "object-oriented programming" means.
>> Then you come here to tell us that you don't want it, whatever it
>> might be.
>>
> I have seen a number of object oriented programs. And I did not like
> what I say.
> They are pretty nigh incomprehensible to me. I know they were produced
> (or claimed to
> be produced) by object oriented programming. Now it's true that the

	OK. Now I'm _really_ confused!

	Was your initial concern that POV-Ray - the *software* - will be coded 
using OOP?

	Or was it that the language that *users* of POV-Ray will have to use to 
describe their scenes will be OO?

	If the former, then your fears are way, way, off, and I suspect along 
with the others, that you don't know what OOP is.

	Yes, POV-Ray 3.7, the *software* will be written in C++, and will very 
likely use OO principles. However, I believe that the actual scripts 
that you as a *user* will write, will stay almost the same.

	*That* should be of really no bother to you. You may not know this, but 
a _huge_ amount of the software that you use was actually written using 
OO principles, in an OO language. Almost all large projects that were 
coded in C++ use OOP (and again, I'm sure you use *many* programs coded 
in C++). Everything written in Java uses OOP. Lots of stuff written in 
Python use OOP.

	Now if your concern is the latter (that you as a *user* will have to 
describe your scene using OOP), then your concerns are not entirely 
unfounded, but they won't be relevant for a while. 3.7 will allow you to 
code as you have mostly done.

	Version 4.0, though, will quite possibly have a different scene 
description language and the syntax you will use to describe your scene 
will be quite different. It's very likely that this will be OO, but as 
I've said a bunch of times, if they make a good SDL, it'll be 
straightforward. It could even be done in a way that a new user will not 
have to know what OO is, and only intermediate or advanced users will 
deal with the details of OOP.


-- 
Thesaurus: prehistoric reptile with a great vocabulary.

Post a reply to this message

Darren New wrote:
> No, that was specifically in response to "I like header files because it 
> gives me a nice summary of the functionality of the code." I'd rather 
> have the specification of the code there once, and to have tools to 
> generate documentation from the code, rather than to have the compiler 
> require me to write the same specification twice just so it knows 
> there's documentation.

Point taken.  I got in the bad habit of using my headers as my 
documentation, and coding my implementations to match them, rather than 
keeping the documentation separate :)

Of course, being Visual Studio, the Class explorer offers similar 
functionality, but it's not in the same form I'm used to from looking at 
header files.  Ah, well, I'll adjust eventually.

> I dunno - on big projects, I usually wind up writing a program that 
> reads my .C files and generates the .H files automatically anyway. But 
> then, I'm the kind of programmer who documents code before writing it, 
> which is apparently terribly rare.

Yes, it is rare.  But good, so keep it up :)

-- 
Chambers

Post a reply to this message