Since you cast Nil to a Picture Nil is assigned to p. This does not trick the compiler into skipping the operator_convert() call, it is just not necessary to call it.[/quote]
No, see above: GetAANilPicture() as defined above returns the Picture SUBCLASS not Picture class.
So it’s more like this is happening:
Dim p As Picture = Picture(GetANilPicture())
which would evaluate as
Dim p As Picture = Picture(dim tmp as Picture = NewPicture.Operator_convert(NIL))
You’ve written this several times.
Its not like that.
At all.
Go reread what I’ve written 2 or 3 times on this thread you’ll see why what IS happening IS correct.
Until then your starting from incorrect assumptions & until you realize that this is a moot conversation.
You’re arguing your point based on incorrect assumptions.
[quote=209100:@Michael Diehr]No, see above: GetAANilPicture() as defined above returns the Picture SUBCLASS not Picture class.
So it’s more like this is happening:
Dim p As Picture = Picture(GetANilPicture())
which would evaluate as
Dim p As Picture = Picture(dim tmp as Picture = NewPicture.Operator_convert(NIL))[/quote]
Again. This assumption is wrong. In the above case the “To”-Operator_Convert method is called, not the “From” one as you indicate.
This is what happens:
Dim p As Picture = Picture(GetANilPicture())
// is nothing else than
Dim p As Picture = Picture(dim tmp as Picture = Nil)
// which is of course
Dim p As Picture = Picture(Nil)
If you would have read my list of programming languages, you’d have seen that I didn’t mention Objective-C. And that for one reason: Objective-C has runtime bindings for message calls (note the word “message” instead of “method”). So there is a runtime library which looks up what method to call on what object depending on the message. If the object is nil, the runtime will just ignore it and not call any method. This is not possible in a programming language with compile time method binding.
If you want to compare it you would have to compare it to Swift. You can’t call a method on a nil object in Swift too (as there are no messages).
Eli and Norman: you guys are both arguing that Xojo works the way it works because it works that way. That’s a circular argument. Not very interesting.
I’m asking whether the way it is designed is correct, useful, helpful, manageable and for lack of a better word, “sensible”. The question is whether or not it would be better for operator_convert (the version that converts FROM one class to another class) to simply return NIL.
(The other discussions may be interesting but are really diversions from the main issue).
Messaging is a computer science term of art which in the abstract sense can include function calls and methods. I’m using it in the generic sense of “asking an class instance object to do something it knows how to do”.
Xojo is an interesting mix of both compile-time type checking and runtime type checking. In case anyone is confused here, I really LIKE the way Xojo is designed for the most part. This particular thread is about an edge case I found where the results were unexpected and hard to deal with when refactoring.
I’ve run into a similar issues with operator convert.
I have Nullable versions of all the primitive types that can Operator_Convert to their primitive.
I find it really annoying that I have to do:
if myClass.myNullableString <> nil and myClass.myNullableString = "Hello" then doSomething()
While it would be convenient for coding to allow this change to Operator_Convert, I understand from a fundamentals standpoint why it shouldn’t be added and it’s better to do the Nil check.
I find Xojo rides a funky balance between 2 programming paradigms
The first being, simplicity and ease of use:
“I usually don’t care about case-sensitivity”
“I want variants to auto-convert into what they should be”
The second being what they’re moving to more recently, especially with the new framework:
“Throw exceptions early and often”
“Explicitly get type and value from Auto”
“Force Text encoding to be defined”
In the sense of the first paradigm, having Nil versions of objects work with Operator_Convert would be helpful and a very “RealStudio” thing to do, yet Xojo seems to be moving away from this type of ideology. The only problem is that the new framework isn’t yet robust enough (see Auto type conversion, how exceptions don’t autofill, etc…) and we’re left in limbo between these two ways of thinking. I love the old school “code faster, worry less” approach but this leaves hard to track down bugs and bad programming practices, and I certainly can appreciate the benefits of the new way. In the spirit of where Xojo is heading, I doubt they would implement this change to Operator_Convert - and as annoying as it is (even for me) I think it is the right decision.
[quote=209449:@Michael Diehr]Eli and Norman: you guys are both arguing that Xojo works the way it works because it works that way. That’s a circular argument. Not very interesting.
I’m asking whether the way it is designed is correct, useful, helpful, manageable and for lack of a better word, “sensible”. The question is whether or not it would be better for operator_convert (the version that converts FROM one class to another class) to simply return NIL.
[/quote]
operator_convert( var as type ) CANNOT return NIL
It HAS no return type
For the same reason CONSTRUCTORS cant return NIL
They aren’t allocators - they are initializers
The object is fully created & exists before your operator_convert is called
Whether you do anything with the instance is up to you but there is no return nil option
[quote=209450:@Michael Diehr]Messaging is a computer science term of art which in the abstract sense can include function calls and methods. I’m using it in the generic sense of “asking an class instance object to do something it knows how to do”.
[/quote]
Not in this case
Obj-C message passing is NOT Xojo functions calls or methods calls in any way shape or form
In Obj-C it can literally ask “do you know how to do this” - there is a “respondsToSelector” that can be used to see IF a class AT RUNTIME has implemented a method
There is no equivalent in Xojo
[quote=209476:@Norman Palardy]operator_convert( var as type ) CANNOT return NIL
[/quote]
That’s not what I’m trying to discuss.
I’m talking about the version that is called on a class instance and returns some other type, not the one you are describing. I think some of the confusion in this thread may be over the terminology we are using (since both styles of operator_convert() convert FROM one thing TO another thing) so it’s not obvious what to call them.
I’ve tired to use the terminology as follows:
MyClass.Operator_convert() as type // the "TO" version, which is called on a class instance and returns an arbitrary Type
operator_convert(var as type) // to "FROM" version, called on a newly instanced class
To clarify, what I believe some of us are saying is this:
MyClass.Operator_convert() as type // the "TO" version, which is called on a class instance and returns an arbitrary Type
// it would be handy and make a lot of sense if this version of Operator_Convert() for NIL was simply defined as NIL.
[quote=209477:@Norman Palardy]Not in this case
Obj-C message passing is NOT Xojo functions calls or methods calls in any way shape or form
In Obj-C it can literally ask “do you know how to do this” - there is a “respondsToSelector” that can be used to see IF a class AT RUNTIME has implemented a method
There is no equivalent in Xojo[/quote]
Sure there is: Xojo has the Introspection() features which lets you query a class instance about what methods it has and then call them. The syntax is difference but the idea is the same. I bet one could write very Cocoa-like code by using operator_Lookup() in conjunction with Introspection().