objects are instances of code data and code methods.

OOP techniques are employed@bluebrain.

Oo is how we think we think.

etc...



trash(object) from the verb, to trash, bin etc.

One idea that drives a tank battalion through the entire OOP paradigm involves defining one "do it all" object, colloquially referred to as the "god object", within a project. If you're going to do this, which effectively circumvents the entire OOP mechanism of separating objects and methods, why bother with OOP at all? Why not just go back to 1960s style BASIC code with global variables and GOTOs?

newolder wrote:objects are instances of code data and code methods.

OOP techniques are employed@bluebrain.

Oo is how we think we think.

etc...

So the core idea of OOP is its take on how to write modular programs. In most programming languages, it is a good idea to separate how something is used from how it works, and this idea has been cashed out in several ways (APIs, protocols, interfaces, signatures). It is sometimes a good idea to make these modules "hot-pluggable", so that they can be replaced and updated live in a system without ever having to do a rebuild.

Many application designs follow this model even if they are not written in a so-called "OOP language". The Linux Kernel is written in C, and has a modular design such that you can replace parts of the kernel while the system is up and running without ever having to reboot. Every service on the internet follows this model as far as the server and client is concerned. I can switch between browsers and web servers can be replaced without having to restart the internet.

The original OOP language (Smalltalk, not Simula), took this idea and built a programming language in it. A Smalltalk system is a huge collection of objects communicating via implicit protocols that can be hot-plugged live. The ability to manipulate a Smalltalk system live without having to rebuild it is so dramatic that the default way to write a program in Smalltalk is simply to fire up the IDE (a Smalltalk program) and then replace modules until you no longer have an IDE, but instead, you have, say, a music player. The idea is taken to further extremes with "reflection", where the modules of the system which define how the core language works can be replaced. Replace some modules, and suddenly, you're not even writing your program in Smalltalk anymore. The possibilities for error are extremely grim, here. It's easy to do something wrong and screw the system up. This is why Smalltalk arguably has the most sophisticated debugger of any programming language to this day. And of course, that debugger is yet another module that can be replaced, as can individual stack frames in some smalltalks. The possibilities for recovering from errors live are limitless.

I wouldn't call any of these stupid ideas. My criticisms are directed at Java, which did its best to ignore all of them. The only motivation behind Java was to make a secure, garbage-collected language that could be marketed at C++ programmers and which could pay lip-service to OOP which was experiencing a wave of hype at the time. Java started calling itself "pure object-oriented", because it required every bit of code to be defined in a class, leading to the Kingdom of Nouns phenomenon. Smalltalk also requires every bit of code to be defined in a class, but doesn't suffer the same headaches. Again, Java was just paying lip-service, and misses the point completely.

There are multiple threads that could be pursued here, and I suggested starting by talking about static versus dynamic typing, or in more accurate but less familiar terms, nominal versus duck typing. Smalltalk is dynamically typed, as are Python, Perl, Javascript, PHP and Ruby. C++, Java and C# are all statically typed. The presence of typing has a significant effect on the way these languages work and what is possible with them. In particular, the concept of inheritance is heavily downplayed in Smalltalk, Python and Ruby compared to C++, Java and C#.

I'll add another reply tomorrow if this isn't enough to get a discussion rolling.

trash(object) from the verb, to trash, bin etc.

This isn't OOP syntax. It's just an ordinary function application, something which you can do in any high-level language (save Prolog). In (single-dispatch) OOP, you don't trash objects. You tell objects to trash themselves. How's that for mimicking the way humans think?

Calilasseia,
Yeah, or we could go back to drawing lines in the dirt. OOP is a recent idea. It built the i-suite. Gods are simple products of the woo method, like those invisible pink unicorns over there ->

Oh, and one idea that has led to a lot of trouble in C++ is allowing child objects to inherit from multiple parents. This has been a source of numerous insidious and troublesome bugs in some large projects. The people responsible for Java specifically forbade multiple inheritance within the Java language because of it.

Within C++, it's possible to define two objects, have them both share a name for a method, then define a third object that inherits from these two, at which point, you have the less than happy scenario of deciding which of the identically named methods from which of the parents is going to be overridden in the child object. Worse still, because of the flexibility of method overloading, I've been told it's possible to have the child object refer to overridden versions of both of the parent methods via the same method label ... which again, drives a sodding tank battalion through the OOP paradigm.

Needless to say, I wouldn't trust a mission critical application to this language platform unless there were very strict rules in place as to what programmers could and couldn't do.

See here as well: http://tunes.org/wiki/object-oriented.html

Oh, and I added a few remarks at the end of my last post and the one in the other thread, newolder. Judging by the example code you are giving, you don't aspire to be an OOP programmer

Thanks VazScep, I didn't know about all these differing meanings and debates - I'm only a physicist and the way I got to oo-land is irrelevant to what it (oo) has achieved already with the intertubez.

Aren't language difficulties dealt with correctly in codecomplete2?

fkn ell. I'm communicating with 2 of the brightest brains I've ever met at 1nce!

objects, objects everywhere.

Calilasseia wrote:Oh, and one idea that has led to a lot of trouble in C++ is allowing child objects to inherit from multiple parents. This has been a source of numerous insidious and troublesome bugs in some large projects. The people responsible for Java specifically forbade multiple inheritance within the Java language because of it.

Within C++, it's possible to define two objects, have them both share a name for a method, then define a third object that inherits from these two, at which point, you have the less than happy scenario of deciding which of the identically named methods from which of the parents is going to be overridden in the child object. Worse still, because of the flexibility of method overloading, I've been told it's possible to have the child object refer to overridden versions of both of the parent methods via the same method label ... which again, drives a sodding tank battalion through the OOP paradigm.

Needless to say, I wouldn't trust a mission critical application to this language platform unless there were very strict rules in place as to what programmers could and couldn't do.

I don't think the ambiguity is really an issue, because the semantics of the look-up are well-defined. The diamond inheritance problem is another matter, where a derived class inherits two copies of an ancestor class by multiply inheriting parents. The correct behaviour here is achieved by explicitly using virtual inheritance, which C++'s programmers generally don't want for performance reasons, so you end up having to plan for multiple inheritance way in advance. This is the whole problem with nominal subtyping: you can plug new classes into an interface scheme, but you can't plug in new class diagrams.

self.trash

self.destroy

either way, self vanishes.

ref wrote:More generally, isolated objects mean nothing, only structured sets of objects do; and these language don't allow to manipulate those sets, to describe their properties. Languages with multiple dispatch, such as CLOS or Cecil, do a better job of not associating environments to objects.

My limited experience is to their definition of “false OO languages” so I can only begin to imagine some of the difficulties you guys up there must be having.

newolder wrote:self.trash

self.destroy

either way, self vanishes.

Does it, though? Objects can't destroy themselves directly. You need another object in there.

One final point, if someone tells you that they have used OOP, or that their product contains OOP concepts, always call bullshit. It really is a buzzword in those contexts.

VazScep wrote:

newolder wrote:self.trash

self.destroy

either way, self vanishes.

Does it, though? Objects can't destroy themselves directly. You need another object in there.

In my mind, self.trash takes the object in focus to the nearest waste receptacle. For example, the object in focus is a 1mm ball of steel in the hand before me. Self.trash causes magnet-like attraction whilst self.destroy makes the ball vanish. Am I way off?

One final point, if someone tells you that they have used OOP, or that their product contains OOP concepts, always call bullshit. It really is a buzzword in those contexts.

Yes.

I always understood the process of instantiating and de-instantiating objects to be performed by entities outside the objects in question. The new and delete operators achieve this. An object can contain within it a constructor method, which is used to tell the new operator how to initialise an object if the creation of an instance is accompanied by relevant initialisation data, and which the new operator calls after it has allocated memory for that object, set up the pointers to the methods, and provided a pointer to the object for the object reference variable to contain. In its simplest form, the delete operator simply returns the allocated memory to the operating system's free list, and sets the object reference variable to some suitable 'null' value to indicate that it's no longer pointing to an object.

More sophisticated versions of delete allow for a destructor method to be called, whose job is to perform tasks that may be necessary before the object can be freed and dereferenced. For example, if the object being created contains within it yet more object reference variables that can contain pointers to other instances of the same object class, facilitating, for example, the construction of a doubly linked list, then it may be necessary to include a destructor method for the class, that checks to see if the instance is currently linked into a doubly linked list, and if so, unlink it from the list before it is deleted. Without such a destructor method, reliance upon the programmer to remember to unlink every linked object from the list introduces an extra source of potential bugs, whereas with the destructor method in place, once it's working of course, the programmer is no longer required to remember to unlink objects intended for deletion from the list, because the destructor method, once it's working, handles that on the programmer's behalf. The programmer can then get on with the business of actually using the objects for something. In the doubly linked list scenario, the constructor method would also provide some means of adding a newly instantiated object to an existing list, or, if the object being instantiated is the first in the list, provide some means of handling this case in a consistent fashion.

Different languages have different syntaxes for handling all of this, of course.

One big problem that needs to be addressed concerns garbage collection. In an environment where garbage collection is provided as an automatic feature of the run-time environment, problems can arise with respect to ensuring that destructors are called, if the programmer simply dereferences the entire list in one fell swoop, using the above doubly linked list example. indeed, there's an entire body of literature on the subject of garbage collection, because ensuring the consistent release of allocated resources (memory, file handles etc) is time consuming, and conflicts with the need to minimise the impact of the run-time environment's ancillary services upon the executing program. Balancing these requirements is one of those particularly difficult computer science problems, and finding a consistent, secure and fast garbage collection method is one of those Holy Grails of computer science that may never be achieved. All of which is compounded yet again when you consider programs that are multi-threaded, even if the threads are actually executed on one processor via the multitasking executive - it's possible, if you're not careful, for one thread to specify that it wants to delete an object at the same time as another thread wants to press that object into use, and synchronising usage versus deletion of objects across threads in a multitasking environment is another nice minefield for the unwary, made all the more hilarious when one implements multithreading on a genuine multiprocessor environment, where the threads are given their own processor to run on.

Calilasseia wrote:I always understood the process of instantiating and de-instantiating objects to be performed by entities outside the objects in question. The new and delete operators achieve this. An object can contain within it a constructor method, which is used to tell the new operator how to initialise an object if the creation of an instance is accompanied by relevant initialisation data, and which the new operator calls after it has allocated memory for that object, set up the pointers to the methods, and provided a pointer to the object for the object reference variable to contain. In its simplest form, the delete operator simply returns the allocated memory to the operating system's free list, and sets the object reference variable to some suitable 'null' value to indicate that it's no longer pointing to an object.

The delete operator only exists in C++. Languages with garbage collection handle all memory management issues themselves. Setting an object's reference to a null value is only good for getting null-pointer dereferences, the behaviour of which as far as C++ is concerned could involve formatting your hard-drive. This isn't stability.

Removing oneself from a doubly-linked list is a very different operation to destroying oneself, so it should be a separate function. In a garbage-collected language, you would call this function explicitly, along with any other functions needed to free finite resources such as file-handles. If you want the small amount of automation that C++ gives you here in terms of automatically calling destructors of stack-allocated objects, you can use "with-open-file" constructs, which declare new objects whose resources are automatically released at the end of their scope, even if exceptions occur.

One big problem that needs to be addressed concerns garbage collection. In an environment where garbage collection is provided as an automatic feature of the run-time environment, problems can arise with respect to ensuring that destructors are called, if the programmer simply dereferences the entire list in one fell swoop, using the above doubly linked list example. indeed, there's an entire body of literature on the subject of garbage collection, because ensuring the consistent release of allocated resources (memory, file handles etc) is time consuming, and conflicts with the need to minimise the impact of the run-time environment's ancillary services upon the executing program.

Destructor issues don't occur in garbage-collected languages, because there generally aren't any destructors. Languages like Python, which uses a very simple reference-counting garbage-collector make destructors somewhat more useful, since the programmer can make strong guarantees about when destructors are called.

Balancing these requirements is one of those particularly difficult computer science problems, and finding a consistent, secure and fast garbage collection method is one of those Holy Grails of computer science that may never be achieved. All of which is compounded yet again when you consider programs that are multi-threaded, even if the threads are actually executed on one processor via the multitasking executive - it's possible, if you're not careful, for one thread to specify that it wants to delete an object at the same time as another thread wants to press that object into use, and synchronising usage versus deletion of objects across threads in a multitasking environment is another nice minefield for the unwary, made all the more hilarious when one implements multithreading on a genuine multiprocessor environment, where the threads are given their own processor to run on.

Finding such a Holy Grail was a goal a few decades ago. The only programmers still seriously worrying about garbage-collector efficiency are systems programmers and people working on embedded devices, who constitute a tiny fraction of all programmers. Garbage collected languages have been the norm for over a decade now. They make your code far safer (no more null-pointer dereferences) and massively boost programmer productivity. Requiring manual memory management everywhere is now just one big exercise in grossly premature optimisation --- most of your code doesn't doesn't need to be that fast, and the average programmer is as likely to do a worse job than the garbage collector would at freeing resources, certainly when it comes to safety. If you need better efficiency in that one tight function, you might just need a smart compiler that will do stack-allocations automatically, or a language which provides stack-allocation primitives (C#'s value types, Lisp's dynamic-extent declaration), or you just need to write your own memory pools.

newolder wrote:In my mind, self.trash takes the object in focus to the nearest waste receptacle. For example, the object in focus is a 1mm ball of steel in the hand before me. Self.trash causes magnet-like attraction whilst self.destroy makes the ball vanish. Am I way off?

I'm not sure. What languages are you familiar with? As Calilasseia said, objects are trashed in OOP languages by entities on the outside. Garbage-collecting languages deal with trash automatically, so this "taking out the trash" metaphor is pretty confused.

self.trash doesn't help you anymore than object.trash. "self" can't generally be used. The main point here is that trashing in the example has become a property of the object. Is that a reasonable assumption to make? Is trashing not equally a property of the trash-can? What about the cupboard under the sink? What about the person who carries the bag? Why is only the trash-bag given sole responsibility here, aside from the fact that Java insists on all verbs being owned by nouns? Do we not have a procedure here, something like:

person.acquireFrom(trashBag, sinkCupboard);
person.goTo(garage);
person.placeIn(trashBag, trashCan);

Now where do we put this procedure? Procedures in Javaland belong to nouns, so we need something like:

trashDisposalPlan.doIt(person, sinkCupboard, garbageCan)

Incidentally, "doIt" methods are common in Java. This is called the "Command Pattern", and is a great example of how OOP has been horribly confused by Java and the "Patterns Community" [*]. The Command Pattern is normally just a crude hack to simulate "first-class functions", which are not available in Java (they are now in C#), and which were always supported by Smalltalk and exploited pervasively.

[*] Design patterns have also been horribly confused by the "Patterns Community".

VazScep wrote:...

newolder wrote:In my mind, self.trash takes the object in focus to the nearest waste receptacle. For example, the object in focus is a 1mm ball of steel in the hand before me. Self.trash causes magnet-like attraction whilst self.destroy makes the ball vanish. Am I way off?

I'm not sure. What languages are you familiar with? As Calilasseia said, objects are trashed in OOP languages by entities on the outside. Garbage-collecting languages deal with trash automatically, so this "taking out the trash" metaphor is pretty confused.

self.trash doesn't help you anymore than object.trash. "self" can't generally be used. The main point here is that trashing in the example has become a property of the object. Is that a reasonable assumption to make? Is trashing not equally a property of the trash-can? What about the cupboard under the sink? What about the person who carries the bag? Why is only the trash-bag given sole responsibility here, aside from the fact that Java insists on all verbs being owned by nouns? Do we not have a procedure here, something like:

person.acquireFrom(trashBag, sinkCupboard);
person.goTo(garage);
person.placeIn(trashBag, trashCan);

Now where do we put this procedure? Procedures in Javaland belong to nouns, so we need something like:

trashDisposalPlan.doIt(person, sinkCupboard, garbageCan)

Incidentally, "doIt" methods are common in Java. This is called the "Command Pattern", and is a great example of how OOP has been horribly confused by Java and the "Patterns Community" [*]. The Command Pattern is normally just a crude hack to simulate "first-class functions", which are not available in Java (they are now in C#), and which were always supported by Smalltalk and exploited pervasively.

[*] Design patterns have also been horribly confused by the "Patterns Community".

Z80-assembly, Basic, Fortran, Pascal (e.g. “Delphi”), VB6, VB and metalanguages like sql etc.

I'm pretty sure I've coded the likes of

With self do
Begin
{code}
End; {With}

before now.

newolder wrote:Z80-assembly, Basic, Fortran, Pascal (e.g. “Delphi”), VB6, VB and metalanguages like sql etc.

Nitpick: SQL isn't a metalanguage anymore than the others are. Any language can be used as a metalanguage, so long as you're using it to define another language (many languages nowadays use themselves as their own metalanguage --- C compilers are written in C)

I'm pretty sure I've coded the likes of

With self do
Begin
{code}
End; {With}

before now.

In this case, when you write self.trash(), you are writing code inside the class which defines trash. Suppose you are calling the trash method from a different class? Then you need to write object.trash().

I find the problems with OOP is mostly centered around coders, not languages. The project I'm working on is done in VB 2010, and has the three layers large apps need. But you know what the data layer passes? Datatables. I mean christ, I might as well be coding in VB6 (and shoot myself in the head while I'm at it). There's no true and proper use of objects anywhere in the 600-odd code files.

VazScep wrote:

newolder wrote:Z80-assembly, Basic, Fortran, Pascal (e.g. “Delphi”), VB6, VB and metalanguages like sql etc.

Nitpick: SQL isn't a metalanguage anymore than the others are. Any language can be used as a metalanguage, so long as you're using it to define another language (many languages nowadays use themselves as their own metalanguage --- C compilers are written in C)

No worries. Code Complete is one of the rubberbibles I keep as a library reference for inter-language semantics.

I'm pretty sure I've coded the likes of

With self do
Begin
{code}
End; {With}

before now.

In this case, when you write self.trash(), you are writing code inside the class which defines trash. Suppose you are calling the trash method from a different class? Then you need to write object.trash().

Didn't I (the 1mm steel ball) inherit the trash method when I was created? My pointers through the vmt are set to go?