2

I read that one of the differences between Object-Based and Object-Oriented is that the former supports Built-in objects(eg., window object in Javascript).So, what exactly is a built-in object and why it isn't there in object-oriented language like java.

sanjeeda
  • 131
  • 1
  • 10
  • They're not particularly different from static variables. – zzzzBov Jul 25 '17 at 16:23
  • 4
    Where'd you read that? It doesn't make a lot of sense--JS doesn't have a "built-in `window` object", the environment in which it runs may *provide* one. E.g., there's no `window` in NodeJS. – Dave Newton Jul 25 '17 at 16:23
  • This distinction makes absolutely no sense. Java, or a Java-like language, may just as well provide built-in objects. – Bergi Jul 25 '17 at 16:29
  • Btw, one could categorise Javascript as an *object-oriented* language and Java a *class-oriented* one. But that's a [separate](https://stackoverflow.com/q/6954293/1048572) [question](https://stackoverflow.com/q/15430004/1048572). – Bergi Jul 25 '17 at 16:30
  • @DaveNewton I don't remember exactly where. But I remember seeing Object-based languages support built-in objects. Just wanted to know what are built-in objects. – sanjeeda Jul 26 '17 at 10:26
  • 1
    Objects provided by the language or ecosystem. – Dave Newton Jul 26 '17 at 10:34

3 Answers3

2

That's not actually the difference between those two terms.

For a programming language to be considered "Object-Oriented", it must support the following four programming concepts:

  1. Inheritance
  2. Encapsulation
  3. Abstraction
  4. Polymorphism

There are many languages that support these "four pillars of OOP" (Java, C/C++, C#, JavaScript, etc.).

Some languages, however, don't. A famous example of that would be what we now call "Classic VB" (Visual Basic prior to the introduction of .NET). That language could simulate inheritance, but there was not actual mechanism built into the language for it, so while "Classic VB" had native objects, it is an "object-based", "not object-oriented", programming language because it does support the concept of objects, but not all the aspects that a true OOP language requires.

It should be noted that many OOP languages are built on the concept of "classes" as the mechanism to generate objects from. And, while this is a very popular way to architect objects, it is not a requirement for a language to be OO. JavaScript does not have classes (despite having a class keyword), it has "prototypes" and they are the architecture upon which objects are implemented.

Your question about "native" objects is not related to any of this. You most likely read that native objects were related to all of this at this Wikipedia page, but that page had many errors on it and I have edited that page to be more accurate. Whether or not a language has "built-in" or "native" objects is not at all related to whether it is object-oriented or object-based, since both types of languages are object-centric (my own term). For example, VB 6 was an object-based language, but supported a wide array of native objects and VB .NET (its successor) is object-oriented and also supports a vast amount of native objects.

I will tell you that a "native" object is simply one that is built right into the language specification itself and the runtime environment has access to it internally. In JavaScript, some examples would be String, Date, Array, RegEx, Math, Object, etc. Note that while, in your question, you mentioned window, window is not a native JavaScript object, that object is supplied by the browser that hosts the JavaScript runtime. If you were running your JavaScript in Node.js, window would not be available because it is not native to JavaScript and Node doesn't provide such an object to the runtime.

Here are some good links to look at to understand OOP concepts and how they work in JavaScript:

Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
  • Isn't Javascript Object-based language? And object based language need not support Inheritance. https://en.wikipedia.org/wiki/Object-based_language – sanjeeda Jul 26 '17 at 10:27
  • @sanjeeda It's not that an object-based language "need not" support inheritance. Object based languages "do not" support the all four of the "pillars of OOP" (abstraction, encapsulation, polymorphism, inheritance) - - JavaScript natively supports all of these. – Scott Marcus Jul 26 '17 at 11:33
0

The window object is the global object. It neither exists in Java nor JavaScript for Node.js because it refers to the browser window.

Read about all global objects here: Global Objects (MDN)

As you can see, there are lots of global objects. The Array global object, for instance, exists in both Java and JavaScript.

ideaboxer
  • 3,863
  • 8
  • 43
  • 62
0

There are 'built in' objects in OO languages like Java (or most people would consider them as such), just think of the base Object (top of the inheritance hierarchy) and many of the most core features of the stuff that is in the standard library.

My impression is that people would be saying that to point out that there are still some objects in JavaScript, however you can't actually declare/create a full featured class like in other languages. But, I mean the array in C# and Java is just as much an object as the one in JavaScript.

In order for someone to refer to a language as being 'Object Oriented' I would assume it needs classes (or a similar construct, struct in Go), which is why you generally wouldn't describe JS as object oriented. That said, classes have been added to ES6 so it's arguably fully object oriented now, just with a weak type system.

evanmcdonnal
  • 46,131
  • 16
  • 104
  • 115
  • 1
    *" for someone to refer to a language as being 'Object Oriented' I would assume it needs classes "* Not at all. See my answer for what constitutes an Object-Oriented Programming language. Classes are not, by any means a requirement. JavaScript doesn't have classes, it has prototypes and is object-oriented. – Scott Marcus Jul 25 '17 at 16:30
  • @ScottMarcus yes, I read your answer. It is far more technically accurate than this. Though I would say even based on your criteria classifying JS as OO is still a fairly open argument. It doesn't really have encapsulation and probably won't anytime soon because the scoping is so loose. – evanmcdonnal Jul 25 '17 at 16:39
  • Huh? Of course JavaScript has encapsulation. The ability to have private data in an object is encapsulation and, of course JavaScript has this. The fact that scope is extremely flexible in JavaScript, doesn't mean it doesn't exist. – Scott Marcus Jul 25 '17 at 16:45
  • 1
    @ScottMarcus what constitutes private? I may be wrong but my impression would be the standard of 'private' isn't the same. It's like pseudo-encaspulation. Can you really prevent access to a field? Can you stop me from modifying the objects structures/definition? – evanmcdonnal Jul 25 '17 at 16:49
  • How would you go about accessing `var x = "private"` inside of a function without the ability to modify the original function? – Scott Marcus Jul 25 '17 at 16:53
  • 1
    @ScottMarcus that's not a property on a class, it's a local var hidden inside a closure/method. You can't attach private fields to the class, therefor it does not have encapsulation, at least not by the definition used for all the traditional OO languages you mentioned. – evanmcdonnal Jul 25 '17 at 17:00
  • I never said it would be a property on a class. JavaScript may not be "class-based", but that doesn't discount it's ability to be OO. By itself, a local variable inside of a constructor function isn't a closure, it acts just as a private class field would. It can be wrapped by public (instance) getter and setter methods (then you'd have a closure) so that the actual data is encapsulated and only an interface to the data is provided - - the implementation is hidden. That's the very definition of encapsulation. – Scott Marcus Jul 25 '17 at 17:04
  • I think you are conflating *how* encapsulation is achieved in traditional class-based OOP languages, with [*what* encapsulation is in OOP](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)), similar to how *implementation* is often confused with *interface*. There is no requirement on how to implement encapsulation in an OOP language, only that it can be done. Traditional class based languages do it most simply by declaring a private class field. Inside a function in JavaScript all formally declared variables are private by default, so you have encapsulation by default. – Scott Marcus Jul 25 '17 at 17:14
  • @ScottMarcus nah, I don't inherently disagree with you but I still think it's an important distinction. If you're making a very technical argument, as you are, I would concede that JS technically has encapsulation. Would I call it that in passing? Hell no. It's not encapsulation by what I would consider the general standard, it's like connotation vs denotation at this point. Hiding a var inside a func so it's private is not something myself (and I would guess the vast majority of devs) would inherently associate with encapsulation. – evanmcdonnal Jul 25 '17 at 17:34
  • *"Hiding a var inside a func so it's private is not something myself (and I would guess the vast majority of devs) would inherently associate with encapsulation"* I think you'll find that is very much untrue. That's the basis for how to set up data properties on an object in JavaScript and properties are the poster child for encapsulation. – Scott Marcus Jul 25 '17 at 17:51
  • @ScottMarcus and JS is one language that most people don't consider to be OO at all (at least not before ES6) while developers working in the any of the big three OO languages would consider this a work around to make up for the languages short comings. And that's because it is. It's a shitty work around to make up for the short comings of not being able to simply decorate a field with private. I can describe C as a functional language as well if you want to stretch the definitions, but would a Scala or Haskell dev think "yes C is really a true functional language", probably not. – evanmcdonnal Jul 25 '17 at 17:53
  • I'll just say that you are throwing around adjectives like "vast majority" and "most" pretty loosely. In my experience, those characterizations are not at all true. I would say that "most" people have considered JavaScript OO for well over a decade. It's absolutely true that JavaScript has always had "perceived" shortcomings, but it's become apparent since the advent of, say, JQuery, that the key point there is "perceived". I think for the last 7 or 8 years, JavaScript has been well known to be an extremely powerful, albeit sometimes non-intuitive language. – Scott Marcus Jul 25 '17 at 18:14