Object-Oriented Programming is...

Kian

At about 41 minutes into the first video, he talks about how he'd like lambdas that don't know anything about the enclosing scope, and how he hasn't seen it in any language. Someone should tell him that C++ has that since it introduced lambdas in C++11. Between that and the previous comment that C++ doesn't have exceptions, I can't really take his opinion very seriously. If he's clueless about the stuff I know, how can I trust him to know anything about the stuff I don't know?

That, and how he seems to like golang.

ScholRLEA

A lot of the problems in the field have nothing to do with programming at all, as I am sure everyone here is aware; 999 times out of 1000, we are in a position where the people trying to discuss the topics have little domain knowledge in common about each others' fields, and there may or may not be anyone who has any domain knowledge relevant to the specific project.

BaconBits

@Gurth said in Object-Oriented Programming is...:

@Reddog said in Object-Oriented Programming is...:

Got to love people who start with the whole industry is wrong but i know the truth.

Isn’t that basically how you start a religion?

No, that's how you start a cult. Or Amway.

If you want to start a religion, you have to say, "I know a way of telling the truth that appeals to your biases."

ScholRLEA

Just got to the Q&A part of Tef's talk, and even I had to say "WTF!" about the C++ instructor who didn't understand the difference between local and dynamic memory. Just when you thought you've heard it all...

I mean, holy fuck, that's like a research chemist who doesn't know the difference between an acid and a base.

Did this guy take "those who can't do, teach" as a fucking mission statement?

Magus

@ScholRLEA I hadn't seen that video. All the Jeff references were beautiful, as was his description of waterfall.

dkf

@ScholRLEA said in Object-Oriented Programming is...:

Did this guy take "those who can't do, teach" as a fucking mission statement?

Those who can't do usually can't teach either. So instead they work in government.

asdf

@dkf said in Object-Oriented Programming is...:

Those who can't do usually can't teach either.

That doesn't necessarily stop them from trying.

I can introduce you to one of my former professors if you need some proof. That guy didn't even understand his own research topic or his own slides. (At least he was unable to answer any questions about either.)

I took his course again the year after because I CBA to actually study for the exam after he had killed all my motivation. The professor who took over after him re-used his crappy slides unaltered and still managed to sound 400% more competent while presenting them although it was her first class ever.

powerlord

@boomzilla said in Object-Oriented Programming is...:

I think that a lot of the hate began when in addition to just writing java you also had to write oodles of obscure xml files in obscure places. There's still some of that, of course, but the rise of annotations has greatly improved that.

There have also been some advancements in certain libraries that allow you to eliminate XML files. For example, Servlet API 3.0 (JavaEE 6) or newer let you put everything that used to be in web.xml inside a Java file that implements the ServletContainerInitializer interface instead. StackOverflow has more details on that.

Spring MVC and Servlets 3.0 - Do you still need web.xml?

In a typical Spring MVC web app, you would declare the DispatcherServlet in web.xml like so  <servlet> <servlet-name>sample</servlet-name> <se...

@blakeyrat said in Object-Oriented Programming is...:

Java has tons of problems, but they're 90% in the JVM and 10% in the actual programming language myself. The biggest criticism I have of the language itself is that its stewards are lazy and don't give a shit. (Which is also the reason the JVM is so awful, hm.)

My understanding is that a lot of the performance issues in Java stems from it being a stack-based virtual machine instead of a register-based virtual machine (like .NET uses).

We know it's possible to do this with Java code simply because Android uses a register-based virtual machine.

@swayde said in Object-Oriented Programming is...:

Dates in java is criminally bad, .net less so, but still not perfect.

Unless someone says "you must use the Java Date class" there's no way you should use it. While Calendar isn't much better, it's still an improvement since it at least supports time zones. Still, you'd be better off with JodaTime, or (if you can use Java 8 ) the newer Time API which is based heavily on JodaTime.

@MZH said in Object-Oriented Programming is...:

Method calls = shared private state = shared global state

Maybe if you squint and tilt your head, but not really.

That confused me as well, but I didn't want to mention it in case there was something I was overlooking. Then I got to the part about abstract and just said "this guy is a fucking idiot" and stopped caring.

powerlord

@asdf said in Object-Oriented Programming is...:

Requiring casts everywhere because of type erasure and because it doesn't support co-/contravariance, which basically defeats the whole point of static typing

I haven't really run into anywhere where type erasure requires me to insert casts. Sure, the compiler does whenever you're using a generic and a type is mentioned.

But yes, generics are contravariant while arrays are covariant. You generally discover this the first time you try assigning something like an ArrayList<SubType> to something expecting a List<Type> Java has bounded wildcards (like C# does) for times when you want to explicitly allow that.

In fact, if you are writing code in Java, it's a good idea to read the Generics chapter (PDF) of Effective Java 2nd edition to see all the gotchas in dealing with generics / type erasure so it doesn't bite you.

WPT

@Yamikuronue said in Object-Oriented Programming is...:

@asdf said in Object-Oriented Programming is...:

I think we can (almost) all agree the Ruby is absolutely horrible.

@asdf said in Object-Oriented Programming is...:

Groovy

Isn't Groovy essentially "Ruby, but more Java-esque"?

It is the bastard child of both Ruby and Java.

asdf

@WPT said in Object-Oriented Programming is...:

It is the bastard child of both Ruby and Java.

OK, OK… I succumb to the peer pressure and will refrain from making positive statements about Groovy from now on. I will also deny ever having stated that any feature of Groovy might be sensible.

NedFodder

@powerlord said in Object-Oriented Programming is...:

My understanding is that a lot of the performance issues in Java stems from it being a stack-based virtual machine instead of a register-based virtual machine (like .NET uses).

.Net also uses a stack-based virtual machine.

dkf

@NedFodder said in Object-Oriented Programming is...:

.Net also uses a stack-based virtual machine.

There's nothing wrong with a stack-based VM model. It's got lots of advantages (easy to generate code for from source, easy to verify that the code isn't doing something insane) and the JIT transformations from there to efficient execution schemes are pretty well known.

Onyx

I'll go with cartman, he makes some good points but he takes it too far. He blames stupid things people do on languages and methodologies, not stupid people.

Personal experience time: the service I'm currently working on as a part of the ongoing project started exactly as he would do things: it was a huge piece of procedural code, only used classes where needed because the framework demanded it, and all data was just a big hash operated on by functions.

You know what happened? I lost control of it. It was too big, too complex, there were too many conditions, too much error checking. It turned into a FP-worthy behemoth nobody could follow, and it was mostly to do with keeping that hash in a consistent state with a system that sent asynchronous messages about its state

Then I stopped and looked at the problem again: the states I was getting from other system were states of objects. So I replicated the bits I needed, discarded some I didn't care about, and added in my own bits where it made sense to my system. I made objects. I separated the data and the methods operating on them and got... readable code you could understand!

Now, I do admit I "cheated" a bit. Yes, I pass pointers to objects around, which is apparently a big no-no in the mythical dragon he's trying to slay. And a large chunk of code is actually still what he'd do: it's a huge switch (well, ok, if-else, you can't switch on strings in C++, let alone string objects) because that's the only thing that actually makes sense without creating a gazzilion unnecessary classes and/or methods. And guess what: that's the most unreadable part of the code. Everything else is decently named and commented, you can follow the flow without understanding the implementation, and is generally at least half-decent code-wise.

Honestly, if I wrote all of this as procedural code I'd go mad by now. Maybe I'm just a bad programmer, I don't know, but I'd say this guy is worse. I am at least capable of admitting my thinking was wrong and adapting. He would, meanwhile, probably still be wrangling that huge hashmap trying to keep it in check. Probably by using a herd of globals.

Also, confession: I did actually succumb to the "too many objects" thing in places, I believe one class is nothing but static methods, that thing should be moved to just a header containing a bunch of functions... One of these days, one of these days...

PleegWat

@Onyx Know your tools. A hashmap is a powerful tool, but if you've got keys foo, bar, and baz which are known in code and handled differently, you really should be using a struct or class instead.

Onyx

@PleegWat Which I did, eventually. It seemed like a simpler problem to start with though, so it was just literally a QMap<QString, QVariant> to begin with (QVariant being a generic container class) since, in the end, it will just end up in a DB table, and I actually have methods that will just spit out a bunch of data as such a structure. But the system was just too complex to keep track of it all in that form, which was my point. Would it be doable? Sure. Would it be cleaner as the guy in the videos claim? Hell no.

PleegWat

@Onyx That very type definition makes me raise my eyebrow. We used to have a lot of PHP code along that flavour.

Onyx

@PleegWat Well, when you think about it it's pretty much what you do in interchange formats like JSON. Actually, it's directly transformable to JSON in Qt. Which makes sense in the context, since all I get is a bunch of strings I then parse and try to make sense of.

RaceProUK

@Onyx said in Object-Oriented Programming is...:

I am at least capable of admitting my thinking was wrong and adapting.

That alone makes you a good ~~programmer~~developer

@Onyx said in Object-Oriented Programming is...:

I believe one class is nothing but static methods, that thing should be moved to just a header containing a bunch of functions

Unfortunately, that's not possible in a lot of OO languages, including the two mainstream mainstays, Java and C#; static classes are the only way; it's actually one of the few things I'd change about C#

Magus

@RaceProUK said in Object-Oriented Programming is...:

Unfortunately, that's not possible in a lot of OO languages, including the two mainstream mainstays, Java and C#; static classes are the only way; it's actually one of the few things I'd change about C#

Honestly, in C#6, the only difference is that you do have to create the class. But now that there's using static System.Math; for example, the class only acts as a namespace.

Captain

@Onyx said in Object-Oriented Programming is...:

Honestly, if I wrote all of this as procedural code I'd go mad by now. Maybe I'm just a bad programmer, I don't know, but I'd say this guy is worse. I am at least capable of admitting my thinking was wrong and adapting. He would, meanwhile, probably still be wrangling that huge hashmap trying to keep it in check. Probably by using a herd of globals.

One nice thing about hashmaps is that as long as distinct maps don't collide, you can "add" them together. So you can make a big hash map by adding up smaller, domain-specific hashmaps.

An object system is a few things brought together:

a collection of methods, organized into "spaces"
a monad that represents an object's scope (i.e., a monad that represents doing things "in" the object, in such a way that things can only escape with your permission but not really). Typically, OO languages use an IO monad for this purpose.
a .or -> operator that knows how to resolve which method to actually call.

There are plenty of object oriented languages that use a hashmap for dispatch. All you really need to define is a global one, and then write yourself an operator that queries the hashmap and calls the right function pointer. (Bonuses include things like functions that make modifying the global hashmap easy, preprocessors or whatever to define syntax, etc.) Once you have a working ., all the code you write can be procedural.

In other words, an object system is a functor that attaches a "class" (a collection of methods and data) to an "object" (which is really just a symbolic identifier in your code).

So, object oriented programming is an architectural scheme that uses the power of a language specific functor without exposing the full power of functors. If you want to use the full power of functors (i.e., define your own functors), you need to do things like use the factory pattern or interfaces to attach methods and data to names or types. Object oriented languages do not (typically) treat functors as first-class values.

Not to go on a Haskell rant, but Haskell focuses on making easily adaptable . operators, with a package called lens which can operate in all kinds of functors instead of just IO. http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html

Magus

@Magus For instance:

using static System.Console;

namespace Program
{
  public static void Main(string[] args)
  {
    WriteLine("How are you today?");
    var response = ReadLine();
    WriteLine("I am very glad you are doing " + response);
  }
}

is now a valid C# program.

RaceProUK

@Magus This is a contrived example, but what if you had this?

using static Package.Alpha; //Has method Foo()
using static Package.Beta; //Has method Foo()

namespace Program
{
    public static void Main()
    {
        Foo();
    }
}

Can you using static Foo = Package.Alpha.Foo;?

Magus

@RaceProUK All you're doing there is proving that headers are a bad idea.

WPT

@asdf said in Object-Oriented Programming is...:

@WPT said in Object-Oriented Programming is...:

It is the bastard child of both Ruby and Java.

OK, OK… I succumb to the peer pressure and will refrain from making positive statements about Groovy from now on. I will also deny ever having stated that any feature of Groovy might be sensible.

I never implied that being a bastard child is negative ;)

Weng

OOP is maligned because the two most likely places for young programmers to see it are, in order of frequency:

At work, in enterprise apps written in Java by cut-rate offshore teams employed by megabucks contracting firms billing for 2-3x of a normal programmer's salary. This is easy to interpret as a direct personal threat to your own livelihood and smacks of stupid corporate decisionmaking, both of which are so bad it's fucking webscale.
That weirdo team of C# developers at work who use all that expensive Micro$loth software. And anything they do CAN'T POSSIBLY be right.

Additionally, when you're learning these days, you ARE absolutely doing mostly toy webby stuff. Toy webby stuff is not OOP's strong point, and is pretty cumbersome compared to just writing some procedural code.

Previously (until about 2010 it seems to me), it was much more common to pick up a C++ or a C# or a Java as a first language, because they were much more readily accessible - your parent's computer had Windows on it, Windows development environments were easy to get, they taught them at grade schools and universities. Now it's all "Go install Python and go nuts, kid!" and "Here's a Raspberry pi with Linux on it!" and "Universities have discovered virtual machines and the Unix guys from the 70's demanded that every lab machine have a Linux VM so they can do their LISP! And the VM also has Python!"

Add to this the loudness of the Functional Programming mafia these days, and it's a wonder the anti-OOP screaming isn't louder.

Frankly, I look forward to being one of the world's foremost experts in doing exceptionally complicated shit. OOP is best suited to arcane bullshit - simulations, etc.

The one thing that really confuses me, though, is that OOP's strength in simulation makes it a natural for building games. And everybody and their fucking dog wants to be a games programmer.

darkmatter

@RaceProUK iirc IDE/compiler just makes you specify which Foo you want in order for it to compile. Same as it worked before at that point. Breaks the classlessness of it, but that's your own fault for including multiple Foo. Same as if you had 2 different namespaces that contain classes of the same name - then you have to create your object with the whole namespace instead of just the shorthand. Pisses me off to no end when 3rd party libraries decide they just have to use common fucking class names for their class name too.

WPT

@Weng

@Weng said in Object-Oriented Programming is...:

The one thing that really confuses me, though, is that OOP's strength in simulation makes it a natural for building games. And everybody and their fucking dog wants to be a games programmer.

Well... Because the game industry portrays itself as earning shitloads of money. Just look at the billions in revenue for the mobile market. However, this is an illusion, hardly anyone outside of the industry would hear of development studios going bust. The only names that people actually associate with games are the names of publishers, that simply provides a platform for publishing games and grabbing a huge share of that revenue. Steam was supposed to help out all these developers by taking away the publishing part in the equation...

Dreikin

@ScholRLEA said in Object-Oriented Programming is...:

I mean, holy fuck, that's like a research chemist who doesn't know the difference between an acid and a base.

What type? Arrhenius? Brønsted–Lowry? Lewis? Some less common classification?

@Weng said in Object-Oriented Programming is...:

The one thing that really confuses me, though, is that OOP's strength in simulation makes it a natural for building games. And everybody and their fucking dog wants to be a games programmer.

I think I'm a bit weird - as much as I love playing games, I've never wanted to be a game programmer. Not even the slightest inclination. My 'dream' program to work on / make is basically going to involve a lot of work with librarians and such.

@WPT said in Object-Oriented Programming is...:

Steam was supposed to help out all these developers by taking away the publishing part in the equation...

They haven't?

dkf

@WPT said in Object-Oriented Programming is...:

Steam was supposed to help out all these developers by taking away the publishing part in the equation...

It's a publication platform, same as it always was. It might have a low barrier to entry and comparatively low overheads, I really don't know about that, but it definitely doesn't eliminate the publisher as a concept. (It also doesn't do much of the marketing side of things, which is quite a large chunk of the non-dev outlay in an AAA game AIUI.)

RaceProUK

@darkmatter said in Object-Oriented Programming is...:

Same as if you had 2 different namespaces that contain classes of the same name - then you have to create your object with the whole namespace instead of just the shorthand.

Unless you using Bar = Package.Alpha.Bar;, but then you'd still have to fully qualify Package.Beta.Bar

dkf

@Captain said in Object-Oriented Programming is...:

In other words, an object system is a functor that attaches a "class" (a collection of methods and data) to an "object" (which is really just a symbolic identifier in your code).

Having actually written an object system from scratch, they're not a simple mapping unless the classes are of the most trivial kind. It's once you add in derivation of one class from another (i.e., inheritance of various types) that things get more complicated, since you have to compute for the classes that you instantiate what the full set of methods they have and what the visibility of those methods is. The problem is made about 100 times more complicated if you support dynamic modification of classes (and under the assumption that users of the object system want their code to go fast); languages like C++ compute the expensive bit during compilation, and Java and C# do it during loading and JITting of the class (as well as keeping the concrete inheritance tree as a true tree, which enormously simplifies the problem).

In a true dynamic object system, a method call is converted to a dispatch of a message to the object (really!) and that message is handled by first resolving it to a sequence of method implementations (this is a linearisation of the inheritance DAG, which is the really costly part) and then walking that sequence. This multi-step scheme works a lot better than anything simpler.

ScholRLEA

@Dreikin said in Object-Oriented Programming is...:

@ScholRLEA said in Object-Oriented Programming is...:

I mean, holy fuck, that's like a research chemist who doesn't know the difference between an acid and a base.

What type? Arrhenius? Brønsted–Lowry? Lewis? Some less common classification?

OK, fair point; being precise in your definitions is important, even if in most practical cases the difference is negligible (e.g., as far as I know, the group of chemicals that meet Lewis' definition regarding electron pair configurations is a superset of those meeting the other definitions, or very nearly so at least).

I would expect a professional chemist working in the field today to have at least a general understanding of each, though, and have a working knowledge of the model that is most appropriate to the specialization they are working in, just as I would expect someone who is paid to teach a programming language in which understanding manual memory management is paramount (C++ in this case) to know the difference between variables temporarily allocated on the program's call stack and variables persistently allocated in heap space, and more to the point, know why it is significant in C/C++ and how it impacts how you need to treat those variables. I realize that they may not be covering dynamic memory allocation in their course, and may not work with it regularly, but when you get past the level of toy problems it is such a fundamental part of programming in that language I would expect them to at least have some clue about it.

Captain

@dkf

Sure, but tree/lattice traversal algorithms are a solved problem and have been for a long time.

ScholRLEA

@dkf

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

Captain

@ScholRLEA

Indeed. The really "deep" part is that closures of the programming variety are really calculations of closures in a lattice. https://en.wikipedia.org/wiki/Closure_operator

just like method resolution is (though that is in a different lattice -- there is a Galois connection between the two different lattices).

dkf

@ScholRLEA

I think I need to hit you with a stick.

In the trivial case, where you are only seeking the most specific implementation for dispatching a method call message to, it's pretty simple. That's what just using closures will get you. Instead, you need to need to resolve to a sequence of implementations (this is so you can call the superclasses' implementations too, which turns out to be really useful) and that makes dispatch less trivial. You can solve it, but making it fast is another good idea as well.

It's not good enough to just think “it's rather like closures” and just hand-wave it. But you should try to do it for real, to production-grade quality and speed, instead of just talking about it. And once you've done that, for bonus marks try making a fast system that allows you to redefine the classes as you go.

If you really want to troll the C++/Java/C# weenies, ask why they have a new operator.

Buddy

@asdf said in Object-Oriented Programming is...:

@WPT said in Object-Oriented Programming is...:

It is the bastard child of both Ruby and Java.

OK, OK… I succumb to the peer pressure and will refrain from making positive statements about Groovy from now on. I will also deny ever having stated that any feature of Groovy might be sensible.

Yeah, don'tget me wrong, I love groovy. You can do a lot of great things with it. But any time you use something, there are gonna be things that frustrate you, and groovy definitely has some.

ScholRLEA

@dkf said in Object-Oriented Programming is...:

@ScholRLEA

I think I need to hit you with a stick.

In the trivial case, where you are only seeking the most specific implementation for dispatching a method call message to, it's pretty simple. That's what just using closures will get you. Instead, you need to need to resolve to a sequence of implementations (this is so you can call the superclasses' implementations too, which turns out to be really useful) and that makes dispatch less trivial. You can solve it, but making it fast is another good idea as well.

It's not good enough to just think “it's rather like closures” and just hand-wave it. But you should try to do it for real, to production-grade quality and speed, instead of just talking about it. And once you've done that, for bonus marks try making a fast system that allows you to redefine the classes as you go.

I have been intending to do exactly that, or at least work towards that goal, but... well, depression sucks. I'm getting better, but it's neither a fast process nor a pleasant one.

Also, creating a professional-quality system is more of a stage N+1 issue for me right now; I have a lot of proof-of-concept stuff to do to show that my design is workable at all first, and then I have to work out how the different parts can be integrated into a whole without too many sharp corners.

If you really want to troll the C++/Java/C# weenies, ask why they have a new operator.

Hmmn, evil, evil...

Dreikin

@dkf said in Object-Oriented Programming is...:

If you really want to troll the C++/Java/C# weenies, ask why they have a new operator.

If my HAG is right:

C++: new is the difference between stack allocation and heap allocation.
Java/C#: carry-over from C++.

Is that anywhere close to right

MathNerdCNU

@Dreikin What if those languages didn't want to use Declare in memory(Dim) syntax because it was associated with VB?

RaceProUK

@Dreikin said in Object-Oriented Programming is...:

Is that anywhere close to right

Well… not really. Well, maybe kinda; it's complicated.

Others will be able to say better for C++ and Java, but I know that C# typically allocates primitives and structs on the stack, and classes on the heap; however, that's a compiler implementation detail, not a language specification detail, so it could change at any point. Couple that with the fact that new is used for both structs and classes, and it's just easier not to make any guesses about allocation strategies ;)

Dreikin

@RaceProUK said in Object-Oriented Programming is...:

@Dreikin said in Object-Oriented Programming is...:

Is that anywhere close to right

Well… not really. Well, maybe kinda; it's complicated.

Others will be able to say better for C++ and Java, but I know that C# typically allocates primitives and structs on the stack, and classes on the heap; however, that's a compiler implementation detail, not a language specification detail, so it could change at any point. Couple that with the fact that new is used for both structs and classes, and it's just easier not to make any guesses about allocation strategies ;)

If I'm reading you correctly, I think we're saying the same thing - a bit of syntax carried over in form from C++ (perhaps I should have said "holdover" instead of "carry-over"?) that doesn't need to be there because it doesn't really add any meaning.

If I'm not reading you correctly, uh, mind trying again?

RaceProUK

@Dreikin What I mean is, new doesn't make any guarantees about allocation; it's all up to the compiler ;)

Dreikin

@MathNerdCNU said in Object-Oriented Programming is...:

@Dreikin What if those languages didn't want to use Declare in memory(Dim) syntax because it was associated with VB?

Eh, tomato tomato. Or vim emacs, as you may wish.

dkf

@RaceProUK said in Object-Oriented Programming is...:

Couple that with the fact that new is used for both structs and classes, and it's just easier not to make any guesses about allocation strategies

Ah, but why is it an operator? It could just be a method on the relevant class object. (Except in C++, which flunked that particular test a long time ago, and has also managed to flunk all the resits since then.)

RaceProUK

@dkf said in Object-Oriented Programming is...:

Ah, but why is it an operator?

Best guess, aside from the convention set by C++ and continued by Java: it's an operator because object instantiation is a 'special' operation that's worth setting apart from static method invocation.

dkf

@RaceProUK said in Object-Oriented Programming is...:

it's an operator because object instantiation is a 'special' operation that's worth setting apart from static method invocation.

It could just be an instance method that goes into native code. It knows what the class object is; it can do the allocation any way it wants (well, according to the language spec, of course) and that's what you get with new now anyway. Instead you've got a magical operator.

The fun thing is that if it was just a method, you could think in terms of subclassing the class of classes to get factories that are integrated into the general language mechanisms. But that tends to scare people…

Dreikin

@dkf said in Object-Oriented Programming is...:

It could just be an instance method

How would that work? Doesn't that lead to a chicken vs. egg problem?

RaceProUK

@dkf said in Object-Oriented Programming is...:

It could just be an instance method that goes into native code.

Static method, shirley? Something like SomeClass.New()