Xojo and OOP annoyances

This is a general thought on some aspects of OOP and how Xojo behave on that matter.
While at first this article may seem a little bit abstract, there are practical implications which, indeed, brought me to start this conversation.

But first, a little disclaimer: I love Xojo, I use it all the time every day from the start when its name was still starting with X. I also appreciate the work of all Xojo people, even if sometimes I don’t agree with them.
The following is not a rant, just some thoughts, personal opinions and, hopefully something that could lead to enhance the Xojo experience.

Among many other things, in Xojo, there is one in particular which boggles me: the fact that, to obtain new functionality from an existing class, I have to subclass it. Someone will say “Hey man, but this is how OOP works! Not only this is wanted, but it’s also a key feature of OOP.” I agree, in general it is.
But, there are times when I just want to add a simple method or property to an existing class, let’s say to a TextField. In this case I have to subclass it, add the required functionality and then changes the existing subclasses of TextField to have as superclass my new TextField. Sometimes this is not even possible, like for classes in plugins or encrypted.

Again, here someone would say that there are no alternatives.
But this is clearly wrong.

This kind of problems is not new, and in fact someone tried to solve it.
As a Mac user which know something of Cocoa and Obj-C, I would take this as example. I believe that, at one point, Apple found that subclassing for just modifying a bit the default behavior of standard events, was a big waste of time and efforts.
So they implemented a Delegate mechanism which is now wide spread among the whole framework.
This is an easy and effective way to avoid subclassing: just implement a delegate to override some default behavior.
Another thing in Cocoa, which sometimes helps to avoid convoluted solutions, is the Notification engine. Standard classes like NSWindow already sends notifications for some important events, like the window going to foreground, closing, etc. For some events there are even double notifications: before and after the event (!).
So, if your instance of whatever class need to be informed when the window activates or the application deactivate, it just need to register to receive this kind of notifications. Again, simple and effective.

But here, we talk about Xojo. So what about it? Are there some mechanisms to minimize the side effects of OOP?

Xojo is by definition an high level framework which permits to spare a lot of time and hassle. It’s probably at an higher level than Cocoa too, so I’d expect to find some similar (or maybe different) mechanism which makes me spare time, efforts and write better code. Unfortunately this is not always the case.

Let’s say for example that I need to create a self contained class, to be used by other developers which don’t need (and don’t want) to know how it works. By definition a class should be some sort of black box and the “user” of this object should be able to access it with the simpler possible interface.
So, what happen if my class need to implement a Timer?
Hmm, following the Xojo way, I should create a Timer subclass and provide some sort of interface to link this Timer to the instance of my class.
Not so hard to do, but my class is no longer self contained and I have to build a convoluted mechanism for storing an instance of MyTimer. If the timer needs to access the code of my class (likely) I have to store into the Timer a reference to my class instance. But wait, this create a circular reference, so then I have to recurse to a WeakRef (and handle it).
Not very neat I’d say.

Another example from real life: I wish my TextField can get when the containing window deactivate. This is not possible without some convoluted code: even if the TextField has focus, TextField.LostFocus event fires BEFORE the Window.Deactivate event, so when my field loose the focus, it can’t know for which reason (user changed focus? window deactivated? window closed? application deactivated?, etc)
Again following the Xojo way I should subclass the Window and provide some signaling mechanism to be consumed from my TextField.

Is it possible we can’t have a better solution from Xojo?

One idea would be to have Notification system in Cocoa style. If the Window class could simply provide some notifications and allows any instance to register for receiving this notification, it would be very simple. No need to subclass, just implement a method.
Yes, I already hear someone saying: “Hey but you can do this yourself! Just subclass Window, then create an interface (see Observer Pattern in Xojo Examples) and subclass EVERY single class which needs to be an observer to implement the purposely created interface.”
Sure, I already done this, but seriously… subclassing every control?
If only this feature could be directly provided from Xojo, it would be a real time saver!

Ah wait, just a moment: with Xojo I have two very powerful tools, delegates and event handlers!
For the Notification system, instead of subclassing every class that could be an observer, I could simply pass a delegate method to the NotificationCenter (like weakAddressOf NotificationReceived). Good, this saved me a lot of work. And the code also remain very simple.

And Back to my first example (the Timer) I could just instantiate a plain Timer inside my class, then wire the Action event of the Timer to a local method using AddHandler. This is very very easy to do, require much less code and classes than the “orthodox” solution and, in the end, I have a really self contained class. Neat!

What’s the problem with this approach?
I see no problem, and in fact I often use this method.
BUT, some people (even from Xojo Inc.) says this is evil and just lead to spaghetti code!
Personally, I see much more spaghetti on the sanctioned way, but perhaps this is because I’m italian, you know spaghetti… :wink:
Btw, I think the only reason why the AddHandler (and RemoveHandler) methods exists is just because Xojo Inc. needs them for building the Xojo IDE. So it’s evil then?

In the end, Im thinking to file a feature request for a Notification system. I just have to find an acceptable way (for Xojo Inc.) for my proposal. Not that I’m holding the breath, for this. It’s likely to be ignored.

And about the AddHandler and Delegates, I believe Xojo should stop suggest academic solutions which require more time to be implemented than the time spared. Without counting the bloating and complexity into the source code.
Apple with Cocoa proved that a delegate mechanism is not evil and works effectively. So why not educating people on this instead of banning it?

Any thought is welcome, but please no flames and bad behavior, thanks. :wink:

[quote=42932:@Massimo Valle]But, there are times when I just want to add a simple method or property to an existing class, let’s say to a TextField. In this case I have to subclass it, add the required functionality and then changes the existing subclasses of TextField to have as superclass my new TextField. Sometimes this is not even possible, like for classes in plugins or encrypted.
[/quote]

You can add methods to a class via “extends”. These methods can’t access the internal, private elements of the class though. Example

Function DaysInMonth(extends dt as Date) As integer End Function

Call it like this:

[code]dim dt as new Date
dim days as integer

days = dt.DaysInMonth[/code]

@Massimo Valle - it sounds like you are really looking for “Categories” rather than “Delegates” (though both are very powerful in Obj-c). Brad has described how to implement something analogous to categories in Xojo using Extends. Delegates can already be done by using the correct design pattern, and is not language-specific.

See here: http://stackoverflow.com/questions/5987679/delegation-over-category.

Extends is exactly what you’re looking for
It’s closest analogy is Objective-C categories

For more information about Extends:

[quote=42956:@Norman Palardy]Extends is exactly what you’re looking for
It’s closest analogy is Objective-C categories[/quote]

Extends is something I already use profusely, thanks.
It’s very useful, albeit this is only syntactic sugar and somewhat limited.
Even without extends I could simply write global methods which takes an instance of a class as an argument and return something.

My post was more targeted to investigate new ways for simplifying work in Xojo.
What about Notifications and pushing the use of delegate methods?

My 2 cents… or should I say nickle as pennies are deprecated?

What’s with multiple inheritance? Why did Xojo decide not to implement it?

I’ve found that there are so many ways to accomplish the same task with different means.
Inheritance, or interfaces, delegates etc.

Multiple Inheritance = Interface.

Norman, can you please adjust the thread?
It appears you edited my post :wink:

This is not quite the same thing … Multiple inheritance would be very convenient.

[quote=43086:@Brian O’Brien]My 2 cents… or should I say nickle as pennies are deprecated?

What’s with multiple inheritance? Why did Xojo decide not to implement it?
[/quote]
Same reasons as Java
http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html

[quote=43090:@Massimo Valle]Norman, can you please adjust the thread?
It appears you edited my post ;)[/quote]
Argggggg so I did by mistake
I meant to quote & reply

I fixed my mistake