OOP Syntax

[Dare]

I think OOP can be implemented by users, via preprocessor.

How would you do debugging? etc ..

IMO, a saleable preprocessor (or translator) it would need some hefty stuff. An IDE, a decent syntax that gelled with PureBasic but was different enough in it's additional keywords and syntax to be obviously the Oop preprocessor, and etc.

This preprocessor would do it's own tokenising/parsing with symantic and syntax checking, etc, yada yada yada. It would chuck errors associated with the original code.

Error-free code would be translated and written to a pure file and this passed to the compiler. If an error then occurs, the preprocessor has a bug (for allowing it to get through).

For we mere hobbyists, lesser tools could suffice. Being non-professionals, we could live with the confusion of having oddball lines numbers thrown at us. We could probably even work out what was actually happening. I know that this is not suitable for (and it appears it would be very difficult for) a professional, but hobbyists/hackers tend to cope.

[Dare]

BTW,

Would an OOP guru explain why this:

Code: Select all

Interface i_counter
  SetCounter(a.l)
  UpdateCounter(a.l)
  GetCounter()
EndInterface
Structure d_counter
  vTable.l
  value.l
EndStructure

Procedure SetCounter(*this.d_counter,v)
  *this\value = v
EndProcedure
Procedure UpdateCounter(*this.d_counter,v)
  *this\value + v
EndProcedure
Procedure GetCounter(*this.d_counter)
  ProcedureReturn *this\value
EndProcedure

Procedure new_Obj()
  *my.d_counter = AllocateMemory(SizeOf(d_counter))
  *my\vTable = ?a_counter
  ProcedureReturn *my
EndProcedure

m.i_counter = new_Obj()

m\SetCounter(0)
Debug m\GetCounter()
For i=1 To 3
  m\UpdateCounter(i)
  Debug m\GetCounter()
Next

DataSection
a_counter:
Data.l @SetCounter(),@UpdateCounter(),@GetCounter()
EndDataSection

is superior to this:

Code: Select all

counter = 0
Debug counter
For i=1 To 3
  counter + i
  Debug counter
Next

I know this is simplistic but anything more complex just adds more complexity. As far as I can see, the Psuedo-Oop is slower (calls to getter/setter type functions) and bulkier, and less readable. I believe this is true also of Oop-oriented languages.

(OK, smarter people can make it tighter, but still not as tight as the simple loop)

Apart from the statement that the real world is OO (which I think is debatable, and which is a throw-away line and does not actually illustrate the advantage of Oop code approach) - what is the advantage?

Please educate me. Genuinely curious. Thanks!

[Mike Stefanik]

i understand there are three catagories, objects, classes, and methods... but euh... i do not understand the difference fully especially the concept of 'classes'

Think of a class as a structure that also contains the functions that are used to manipulate the members of that structure. Those functions are called "methods" and an "object" is an instance of that structure and its functions.

In reality it's a bit more complex than that, but that's a very simple way of thinking of it from the perspective of a procedural language. One of the hurdles that a lot of people who are new to OOP initially struggle with is just the terminology. Instead of declaring a variable, you create an instance of the class; instead of calling a function, you send a message to an object so it will perform one of its methods, and so on.

While it's a useful way to create that mental bridge between functional and object oriented languages, keep in mind that OOP is more than just different terminology and syntax. It's also a fundamentally different way of thinking about how to solve a problem. It's one of those things that, when you think about it and start working with it, the lightbulb comes on and then it's all second nature and you'll have no idea why it seemed like such a foreign concept.

[Mike Stefanik]

I know this is simplistic but anything more complex just adds more complexity.

Actually, the inverse is true. Where OOP shines is when the problem(s) being solved are increasingly complex. It's is not a magical solution for every problem; in some cases, expressing the solution functionally is more efficient and easier to maintain.

When all you have is a hammer, you tend to think that every problem looks like a nail. Like other aspects of programming, the key is using the right tool for the right job.

[Dare]

Hi Mike,

Thanks for the response. Do you mean simpler in "readability" or in actual end-product (app generated)?

I agree that OOP syntax is nice to read. However I think it could produce mammoth code, with functions calling functions, extra data, etc.

BTW, I agree as well that OOP is a way of thinking.

I also agree that different tools do different jobs. But .. both OOP and Procedural do the same job, don't they - produce an end product. So now we have a hammer and a sledge hammer analogy (your choice as to which is which). Maybe hammer with nice rubber encased handle and hammer without nice rubber encasing is a better analogy. One looks and feels better, perhaps. Both drive in the nail.

[mp303]

I also agree that different tools do different jobs. But .. both OOP and Procedural do the same job, don't they - produce an end product. So now we have a hammer and a sledge hammer analogy (your choice as to which is which). Maybe hammer with nice rubber encased handle and hammer without nice rubber encasing is a better analogy. One looks and feels better, perhaps. Both drive in the nail.

The analogy is more like a hammer and wrench, I think - not just two kinds of hammers. (again, your choice as to which is which) ... they're different tools - while you wouldn't need two kinds of hammers (probably), you may very well have a use for two or more different tools.

So your hammer and sledge hammer analogy would probably be a better parallel to two different languages - for example, a Basic language with some OOP, as compared to for example Java with a huge set of OOP language constructs. (the sledge hammer, hehe )

The example you provided above sort of asenine - it's the sort of whack-job you might see a beginning Java programmer turn out, since Java is a language that encourages you (in some situations forces you) to do strictly OOP.

If a language like PB was enhanced with OOP keywords, that is (hopefullly) not the sort of code you'd see an experienced programmer turn out. Especially not if he's tryingt to program a game, or, well, anything performance critical, really. In terms of games especially, I've seen some pretty scary stuff done in Java - like a breakout game where every brick was an object. Creepy. One of the first rules of thumb when doing performance-ciritical OOP, is to consider wether an entity is complex enough to justify writing a class for it...

[netmaestro]

In the lowest level of programming possible, the coder writes one instruction or command and it results in one operation. In a high-level OOP language, when the programmer writes a line of code it often results in a whole structured flurry of operations being executed. There are some good aspects to this and some bad. Looking at the good for a moment, the programmer writes something like CreateApp() with a few arguments and Voila! - a working program. He's expended all of five minutes' effort and he has something useful to show for it. This can be a real advantage when he's creating a large solution with many components. Not having to consider the nuts-and-bolts of the individual parts lets him concentrate on the whole structure and how it fits together. But there's a couple of downsides. Downside 1: He often doesn't understand what the hell he just did. So as long as all the little components are working the way he wants, no problem. But what if one's broken? How does he fix it? He can't. He just has to try again, maybe with some new parameters and hope he has better luck. He's really shooting in the dark. Downside 2: Because the OOP structure of the solution is so high-level, it is also bloated. Just look at the number of lines of code you need to implement OOP and you'll see how significant an effect it has. When Corel switched from C to Java for their office suite, the speed dropped so badly it nearly sunk their whole company. Sure, you're making programming more accessible to the masses but you're paying a price in speed and size, not to mention that the guy who wrote the program doesn't understand all of it. My opinion is that if you've got the wits and the time to put together a well-structured procedural program, you're getting something that will be light and fast and you'll understand every jot and tittle of it. That's worth a lot in my book.

[Dare]

Hi mp303.

Yep, the example is asinine. I guess it is a bit like you said with the experienced programmer deciding when something needs a class, it is a case of deciding when an example can be kept short. I would hazard a guess that a more complex example would contain more bulk, either up-front like PureBasic, or behind the scenes in the little black boxes.

Hi netmaestro,

Your point about CreateApp("Accounts_Receivable") struck a chord. I would certainly want something that lifted the productivity of my programmers. So I guess that price of the rubber-handled hammer is made up in the fact the wielders can drive in more nails per second and perhaps with less calluses. So more expensive -v- greater productivity.

What about throughput? How does an OOP (with potentially more - perhaps buried away - function call and data accesses) stand up?

[fsw]

EnableOOP just speeds up things like:

Code: Select all

a = 5 : Class Test : p.l = 5 : EndClass

And you could use the new keywords outside EnableOOP/DisableOOP as
variables.

Don't think it's so beneficial. The user is already used to not use PB keywords elsewhere as variables and such, why should he be able to use OOP keywords elsewhere?
It's not logical to me.

And for the NewObject approach with the arrays in the output disables
a use of objects in a linked list AFAIK. For me, something like

Code: Select all

obj.CLASS = new CLASS(5, 4)
delete obj

NewList LL.CLASS()
AddElement(LL())
LL() = new CLASS(3, 4)

Dim AA.CLASS(20)
AA(0) = new CLASS(1, 2)

Would be ideal. CLASS(1, 2) calls the constructor with the parameters 1,2.

Thanks for this explanation.

[Mike Stefanik]

Thanks for the response. Do you mean simpler in "readability" or in actual end-product (app generated)?

I agree that OOP syntax is nice to read. However I think it could produce mammoth code, with functions calling functions, extra data, etc.

Object oriented code, in my personal opinion, is easier to read and maintain than functional code. However, I've also been programming in C++ for many years, and more recently, C#. The "readability" of something is very subjective, so it really depends on the programmer.

In general, object oriented programming languages tend to create larger executables. To some extent that's because of the infrastructure of the language itself, but mostly it's because of the class libraries that are typically linked in. Note that doesn't mean that object oriented code is inherently slower than functional code; that depends on implementation. It just means that its typically larger.

If you want a practical example of where OOP is beneficial, just consider Windows programming and its massive API. As an example, let's say that you wanted to change the the Z-order of a window so that it was brought to the front. Quick, using the SDK and without looking at the API reference, how would you do that?

Here, I'll give you a hint: it's the SetWindowPos function. Now, what are all of the arguments that you need to pass to it? Another hint: there's 7 arguments to the SetWindowsPos function.

So, with SDK style programming, you end up writing code that would look like this:

Code: Select all

bResult = SetWindowPos(hWnd, HWND_TOP, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE|SWP_SHOWWINDOW);

The last argument to SetWindowsPos has about 15 bitflags, I've just used three of them. Can you remember them all? (I know I sure as heck can't).

However, in an object oriented language, you'd have something like a CWindow class and you could have a method like:

Code: Select all

bResult = myWindow.Show();

Because the API is encapsulated in a class, you don't need to worry about all of those complex API calls and what the parameters are because they're "wrapped" by methods in the class. And, because that CWindow class serves as the "base class" for other window objects, that means that the Show method above could be used for all kinds of windows.

The programmer doesn't need to understand how Show() works, or that under the covers, it calls SetWindowPos with a lot of arguments and bitflags he knows nothing about. He just knows that it works.

Of course, that's just a simple example. But the basic idea is that it lets the consumer of that object (the programmer) focus on the result, not the implementation. On the other hand, that's why some programmers object (no pun intended) to OOP. They feel that it isolates you too much from the underlying system and presents too much of a "black box" to the programmer. They argue that instead of being a "real programmer", you're little more than an assembly line worker, fitting together the pieces of a jigsaw puzzle (mostly) created by someone else.

Like I said, it's all a matter of perspective.

[utopiomania]

Because the API is encapsulated in a class

What's the difference in encapsulating the API in a class, or wrapping it in a procedure, or even a template?

[Mike Stefanik]

The primary advantage is that you can create a hierarchy of classes that allow you to reuse alot of the same core code. For example, you can have a CToolBar class which derives from a CControl class which derives from a CWindow class. If you make a change to the CWindow class to add a new feature, improve some functionality or fix a bug, every class that derives from it automatically gets the benefit of that change. So, if you add a method to the CWindow class named Hide() which makes the window invisible, that means that CToolBar now automatically has a new method named Hide() which will hide the toolbar. No additional coding needed.

A big part of object oriented programming is seeing things in terms of relationships, whether an object is "a kind of" another object, a "type of" specific object or a container for an object (as is the case with inner/outer classes). As I said in a different post, it's a fundamentally different way of thinking about a problem and how to solve it, not just syntatical or implementation differences for the sake of being different.

[mp303]

In a high-level OOP language, when the programmer writes a line of code it often results in a whole structured flurry of operations being executed.

I think you're confusing language and framework here ... Yes, in a high-level framework, a lot of implicit operations may happen every time you create an object, destroy an object, call a method etc.

But wether a whole lot of implicit operations occur when you do something, is entirely up to the OOP framework you're programming against, and not a direct consequence of the language being OOP, at all.

Of course an application ported from C++ to Java would suffer a serious performance hit. But if you want to compare Java and C++, you can't just compare the syntax of the languages - you also have to compare the object framework, and the fact that Java runs in a painfully slow virtual machine. In that respect, Java is crap, if you ask me. I like the language as such - I do not like the complex, bloated framework, or the fact that everything has to run in a VM.

I do not wish for some sort of heavy-weight OOP framework for PB - I don't need a framework at all, for that matter. But I could use some OOP features, primarily so I can more easily structure my code, make it more easily reusable and extensible.

To your point of writing "CreateApp() with a few arguments and Voila! - a working program" - isn't that basically what you do in PureBasic? It is fairly high-level, isn't it? At least when it comes to Windowed applications and games. Yes, you can do low-level stuff too, which is one of the excellent strengths of PB - and the high-level stuff is even very lightweight and very fast, which is more than I can say for most other languages I know. If I had tried to implement that little game I wrote, and had to do it by mingling with DirectX directly, my guess is the code would have been about five times bulkier...

In fact, this is probably the thing I admire the most about PureBasic - you can mix low-level and high-level stuff very easily. The high-level functions are there, and they're very compact and efficient - and then, if you need a low-level function, this usually integrates into your code pretty smoothly.

Now if only I could do all that and structure it with objects.

[Kale]

The primary advantage is that you can create a hierarchy of classes that allow you to reuse alot of the same core code.

But probably not. There are lots of arguments from OOP developers that they really don't reuse as much as they perhaps should.
http://www.ddj.com/184410808

You can have a CToolBar class which derives from a CControl class which derives from a CWindow class. If you make a change to the CWindow class to add a new feature, improve some functionality or fix a bug, every class that derives from it automatically gets the benefit of that change.

..., every class that derives from it automatically gets the benefit of that bloat.

So, if you add a method to the CWindow class named Hide() which makes the window invisible, that means that CToolBar now automatically has a new method named Hide() which will hide the toolbar. No additional coding needed.

No additional coding needed, for 'features' you might never use, cool!

I couldnt resist!

[Mike Stefanik]

The only way that you get "bloat" is if you actually use the method. A well written linker that groks function-level linking is not going to include code in the executable that isn't called.

And frankly, this fascination that some developers have with minimalist coding is very.. 1980s. We're not running on IBM PC XTs with 640K of memory and twin floppy drives. I honestly don't care if an application takes up 100K or 10Mb, as long as it does the job that I need it to do. I have plenty of diskspace, plenty of physical memory and more virtual memory than I'm fairly certain I'll ever use. Heck, even with Visual Studio 2005 running along with a bunch of development tools, my system never goes over 10% memory utilization.

The only environment I see a real justification in prioritizing executable size over things like rapid development, code reuse and maintainability is when you're working with embedded systems with a very limited resource configuration. Then, squeezing the most out of every instruction and clock cycle makes sense. But for your typical keyboard-bound business application? It makes no sense at all.

The biggest resistance to OOP generally comes from one of two camps. The first are the folks who just don't understand it conceptually, so they don't see why it would be of any benefit. They tend to think of it as just another way to do functional programming. The other camp are the folks that understand it, but fall into the "old dog, new tricks" category -- what they know works for them, and they're just not interested in changing their programming style, habits and methodology.