Talk:Object (computer science)

This should be moved back to Object (object-oriented programming) for two reasons.

1. It would be consistent with other topics uner OOP
2. There are other examples of objects in computer science which do not strictly conform to the definition given in this article. e.g. the Old Object model of Visual Basic.

---

Sorry but this really doesn't make sense at all. -- Taku 07:03, Oct 13, 2003 (UTC)

personaly, i think it should all stay here, and a redirect from Object (object-oriented programming) to here. tooto 17:21, 6 Aug 2004 (UTC)

---

Object also receives a redirection from Data Object and is a much more general concept in computer science. Wikipedia needs 2 pages, Object (general) and Object (object-oriented programming). The pages should point one to another showing that one is the specialization of the other.

Geraldo Xexéo (talk) 19:11, 27 January 2009 (UTC)

Removed some material to avoid mis-attribution

When editing said page, Taku moved some items to Talk: and then signed his action. Unfortunately, unless you follow the edit history, it then becomes difficult to separate what he said from what he is signing.

Therefore, I deleted the material and left only the fact that he moved it from said page.

Is the sample source code mis-leading?

Isn't example in this hypothetical language a little bit mis-leading? Shouldn't Fido and Princess be declared of type Dog? Why not use something standard such as Java or C++ in the first place? --Esad 17:15, 8 Feb 2005 (UTC)jai ho

Class-based only

This article on talks about class-based OOP. Wouter Lievens 12:30, 3 Apr 2005 (UTC)

I know. That's a problem. -- Taku 18:45, Apr 3, 2005 (UTC)

Circular links

Under the heading "Objects in Object-Oriented Programming", instantiating points a disambiguate page which leads you to Instance (programming) which is a redirect to Object (computer science). In the next para, Instance points to Instance (programming) which, as before, redirects you back to Object (computer science).

I know you OO types love being self-referential, but it doesn't work so well in a Wiki... Shermozle 15:09, 15 December 2005 (UTC)

Thanks for pointing this out. It's still a problem... —Pengo 11:28, 30 May 2006 (UTC)

Now it appears to point to instantiation, which is a disambiguation page. I think I will remove this link altogether. --Spoon! 07:07, 4 September 2006 (UTC)

Add some examples

Please add some examples to this article. --Gary King 02:25, 26 January 2006 (UTC)

SUUUUUCAAAAAAA :P

Best Quote Ever

"The God object is an example of an anti-pattern." I love it. Out there. I was trying to research programming languages and ended up feeling like I was looking into philosophy and theology. Anyway, I think that sentence would do well to include a brief decription of what is meant by an anti-pattern. You can click through to the link, but I think that the references in the article should be a bit more contained. It's a zinger of a sentence, but it refers to a very specific piece of knowledge that the article shouldn't assume the average reader has. Some minor explanation here would go a long way to make it a little bit less of a 'WTF?'-sounding statement. It almost comes across as a bit of sensationalism. Almost.

It is, however, a fascinating article. Kudos to those of you who put this thing together.

A candidate for deletion?

"For example, a diagram of a computer monitor is a class (let's call it monitor_class). The actual computer monitor you are looking into is an instance of that class, hence an object"

Eh? Which is the class? Is it the diagram or the computer monitor? If you instantiate an object of class "diagram" you get an instance of "diagram", not an instance of a "computer monitor". Perhaps it's trying to make an analagy between a diagram and a class definition, but if it is, then it's a poor one, poorly stated.

There are lots of other errors in this article as well. But are they worth fixing, is there anything here not already said in the object-oriented programming article?

Any reason why this article shouldn't be nominated for deletion? --Malleus Fatuarum 03:05, 12 August 2007 (UTC)

There is no reason why this article should be nominated for deletion, if you find errors then tag them with an appropriate template or fix it --Zven (talk) 02:49, 16 April 2008 (UTC)

While possibly unclear the sentence quoted is not wrong, or at least not wrong for the reasons you imply. While it is true that if you instantiate an object of class "diagram" you get an instance of "diagram". However an instance of one class might well be a class, eg. instances of the class of classes. This is a useful concept in metaprograming. In the case of the sentence quoted the problem is that it is hard to see the diagram for monitors as being the class of monitors. However it's easy to see the diagram as a representation of the class of monitors. A better wording might be For example, a diagram of a computer monitor specifies a class. The actual computer monitor you are looking into is an instance of that class, hence an object. Taemyr (talk) 09:20, 16 April 2008 (UTC)

Whatever happens, do not delete this article, or at least give ample warning so I can copy the stuff off it so I can personally refer back to it. --AnAbsolutelyOriginalUsername42 (talk) 19:50, 21 February 2010 (UTC)

Merge section into OOPL

The section "Object-oriented labguages" should be merged into object-oriented programming language and deleted. All the best, --Jorge Stolfi (talk) 17:35, 12 May 2009 (UTC)

Drivel

This article is basically drivel. It confuses several issues: it pretends to be some general defintion of object in computer science, but it's mostly about objects in programming languages. It's also not focused on the technical aspects of an object, but on OOP advocacy. It's a also a brain dump of random OOP topics having object in their name. Pcap ping 06:35, 27 August 2009 (UTC)

There seems to be a strange war going on between advocates of object based languages and advocates of non-object based languages. Who cares? Just make the article useful for people who want to know about objects. --AnAbsolutelyOriginalUsername42 (talk) 19:52, 21 February 2010 (UTC)

Can we implement OO in any language?!!

This article says "However, objects and object-oriented programming can be implemented in any language." I think it is not true!!! for example, how can someone implement OO in Basic or C? I think this line should be removed.

C support function pointers, so you can make structs that contain both the data and the assosiated functionality. You can also program using explicit *this pointerst. That said, the sentence is unreferenced, and lacks context, so feel free to remove it. Taemyr (talk) 12:32, 30 August 2009 (UTC)

Partially, depending on what features of OO are considered essential. See Object-oriented programming#Main features. By the way, this article should probably not contain such a discussion, it's off-topic here. See my rant above. Pcap ping 19:24, 30 August 2009 (UTC)

There seems to be a common misconception in the OOP community that the mere act of combining data and "pointers" somehow creates an "OOP-like" object/method and this is therefore Ipso facto "OOP". A pointer - in its usual sense - is merely a fully resolved reference to an absolute location in memory (in this case usually the absolute address the start of a subroutine). References (to subroutines) however, can take many forms such as:-

• the actual names of the subroutines (possibly requiring prior dynamic loading by the operating system),
• a symbolic name of a subroutine - located within the program itself and is essentially
  • - an offset to a label in the program from another fixed label (eg X'01d8' or X'02F6')
• an index to a list of subroutines (1=first, 2= 2nd and so on)

The last one of these is language independent, machine independent and entirely portable across an entire range of systems. It has also the potential to be:-

• the simple basis of a branch table in assembly language (offering great efficiency) or
• the subject of a Switch statement in many HLL programs (potentially offering efficiency - if it's an optimized SWITCH)

Since the index value to a subroutine is essentially also just a data value, combining data variables with a subroutine number - within the same structure - meets the above (limited) view of what consitutes an OOP-like program. I have programmed most of my many successful products (and one off programs) using this "machine & language independent pointer" method for more than 40 years via control tables - which are also essentially entirely portable. This was mostly acheived using assembly language but could equally be implemented in any language. Does this mean that OOP was "invented" by me - no, of course not, it means that combining pointers and data is nothing new and certainly not unique to OOP. It also means that, as PC programmers battled with the primitive micro, they re-invented the wheel many times and gave prior art new names, often without the insight that puts it in its proper perspective. Of course OOP can be implemented in any language and actual pointers are not a necessary prerequisite - as I hope I have explained. This leaves the wider question of whether OOP is necessary or worthwhile - I personally think it is neither and merely confuses programming ken (talk) 10:52, 2 September 2009 (UTC)

weird code snippet

1 int result = 1 0; should be changed to 1 int result = 1; ?

Not That Helpful

I don't understand OOP or objects. I tried to read this article to help rectify that. I have to say it was not that helpful. I agree with Gary King and AnAbsolutelyOriginalUsername42 above. Especially I'd like to see a simple example of a real problem which is best solved with an OOP and by means of explanation showing how much more difficult it is to solve with a non-OOP.Squid57squid (talk) 11:17, 8 April 2010 (UTC)

I can easily recognize your problem - "understanding" OOP is a near impossible task - as it seems almost everybody connected with it is so blind to the alternatives that they fail to see its obvious shortcomings. Many don't really understand OOP themselves well enough to explain it to others. I have for a long time now, like you, been trying to get someone to show me an example demonstrating the so called advantages of OOP (preferably using simple arithmetic - not barking mad dogs saving Timmy!). One of the biggest claimed advantages is encapsulation. An "OOP object" is supposed to be "data plus its methods" - but serialization does not serialize the method component (only the data and attributes) - the method component is quietly and conveniently forgotten! The resultant serialized data (object?) completely lacks the very methods that were previously considered to be an integral part of the object! How do the OOP protagonists get around this? (I suppose they will try to argue that the methods are hanging around on various libraries waiting to be reconnected - I don't accept that excuse and believe that if OOP objects are indeed "real", they should be, as implied, properly encapsulated. Colt45's or dogs carry their "methods" (fire, bark etc) physically around with them - not stuck on some disconnected far-off entity. This is especially relevant to distributed programming environments - so even more important now than before. Also, OOP is supposed to reduce coding/maintenance costs via "code re-use" but this was possible (and in regular commercial use) in source macros/modular programming/libraries in the 1960's. Nothing new there then - and, in fact, OOP code appears incredibly bloated by comparison. Data (and code) hiding are as daft as they sound. Would a car designer ignore the engine or its efficiency when constructing a vehicle - of course not. Good engineers are not only respected for their knowledge of a subject, they are passionate about efficiency themselves - and rightly so. These are all inconvenient truths for OOP admirers/defenders. OOP critics are ostracized for daring to point out the glaring holes in the OOP paradigm/arguments but, because of the continual computer science training being perpetutated in universities and colleges, the sad myth continues unabated ken (talk) 06:57, 18 May 2010 (UTC)

Software Component

We should replace the article "Component-based software engineering" with "Software Component," or at least reinstate the "Software Component" article as an independent item.

See http://en.wikipedia.org/wiki/Talk:Component-based_software_engineering#Software_Component

Contact: juan2000@iJSolve.com —Preceding unsigned comment added by John2000 (talk • contribs) 23:34, 11 April 2010 (UTC)

Poorly explained article

Wikipedia is supposed to be like an encyclopedia. I can't see Encyclopedia Brittanica writing an article like this. Technicians should not be allowed to write encyclopedia articles. It takes a science writer to do it. — Preceding unsigned comment added by Two Wrongs (talk • contribs) 02:55, 27 January 2011 (UTC)