So I learned something rather new today about Operator_Convert: if you are using the conversion *from* version of the overload, then an instance is created for you! It makes sense, once you think about it for a while, but it certainly isn't clearly documented.
Imagine this scenario:
Sub Operator_Convert( i as Integer )
mSomeInt = i
End Sub
Oftentimes, I would write code like this:
dim foo as new Bar
foo = 12
and the reason I would write it that way is because I was assuming that the compiler would essentially treat the assignment like this:
foo.Operator_Convert( 12 )
Boy was I wrong! Instead, the compiler treats it like this:
foo = new Bar
foo.Operator_Convert( 12 )
So essentially, my initial call to new was wasted cycles. This is usually harmless, but can actually lead to some interesting results. For instance, what if the class did some work in the Destructor. That may fire sooner than you'd expect!
The moral of the story is that when using Operator_Convert( from ), you can just do the assignment yourself -- object creation is handled for you!
dim foo as Bar = 12
Ta da!
I always thought that Operator_Convert was a strange addition to the language. Superficially the code may read easier but in the long run it really becomes harder and trickier.
It just seems to be a 'too clever' feature.
I wonder if some things are added to REALbasic because other languages have them? If so, I don't think that I want them.
I like the fact that the REAL engineers have made the (very hard job of) programing easier by making REALbasic simple to use. You guys are my filters between complexity, Fads and low level bit and bytes. Simple. Straightforward. Obvious, not "look how clever this is. I can overload the + sign to add two objects together" clever.
I guess I am rambling a bit now, but I just want it known that I hope that additions to the language are:
a) rare
b) debated extensively before implementation
c) Not added just because Java/PHP/etc/... has them
d) Do not increase the overall complexity of the language.
e) Does not increase the number of calls to the Support telephone number ;-)
Simple. Straightforward. Obvious. That's the vibe I like about REALbasic. For me, Operator_Convert seems to go against this grain.
Thanks Aaron.
GH: Well said.
I expect most features like this come from the market drive of porting VB apps to RB, not trying to keep up with Language Jones'. I'm curious how big a segment the VB converts are to the RB community.
/Explicit is better than implicit.
The operator overloading functionality may seem like fluff, but it's a power feature which enables more functionality. Can it be confusing when used improperly? Certainly! But so can method overloading (the two concepts are the same, after all).
The conversion operator can be confusing when misused because you can do some truly horrible thing with it. You can convert a Person into an Apple, for instance. However, you can also do some very powerful things with it, like converting a MemoryBlock into a COM object, or an Int32 into an Int16.
Language additions are debated internally to a large extent, but I would not say they're rare by any means. However, to claim that they shouldn't add to the complexity of the overall language is a bit unfair -- adding anything means the language becomes more complex by its very definition.
One thing to keep in mind when it comes to language features is: if you don't understand why you'd use it (even after someone explaining situations), doesn't mean that it's a bad thing. Most people have no idea why we added namespaces. However, without them, there are entire classes of problems which become impossible to solve gracefully.
My macoslib code for Core Foundation uses Operator_Convert all over the place. I find it really useful in certain situations.