What should operator_convert do with a nil object?

[quote=208896:@Eli Ott]This is equivalent to:

Dim p As Picture = Picture(Nil)

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))

Perhaps we aren’t communicating well?

The semantics of NIL is completely left up to the compiler designer. A human.

As I pointed out earlier, in Objective C, messages sent to NIL are ignored. That’s not because Objective C is magical, it’s just a design difference.

On the other hand, here in Xojo, messages (functions) called on NIL trigger a Nil Object Exception.

However, Xojo will let you cast a NIL object of one “class” to any other class.

I find these a little discrepant.

So, restated: here’s my argument in a nutshell:

  • If it’s legal to Cast nil to any class
  • Then it should be legal to operator_convert() nil to any class.

I have to agree. A simple

If obj is nil then return nil

supplied by the compiler would be helpful and not break any code that wasn’t already broken.

What is “Obj” here? If it’s Self, then it’s never going to be Nil. If it’s the object being converted FROM then why is a value being returned?

It is self, and it IS nil. That is the OP’s problem.

It should do exactly what it IS doing

You’re assuming that the invocation of the CONVERT TO form of operator_convert is like

      variable = someClassInstance.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).

There are no message calls in Xojo. There are method calls, which need to be resolved at compile time.

[quote=209101:@Michael Diehr]So, restated: here’s my argument in a nutshell:

If it’s legal to Cast nil to any class.
Then it should be legal to operator_convert() nil to any class.[/quote]

The two things are not related to each other at all. The first is a cast, the latter a method call.

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().

They’re more different than the same
Conceptually they’re aren’t the same

[quote=209488:@Michael Diehr]

MyClass.Operator_convert() as type [/quote]

if as the code you posted so long ago does and sets MyClass, a class reference, to NIL you want

  NIL.Operator_convert() as type 

to do what ?
Remember what its declared type is and call that things operator_convert ?
That could silently mask bugs or cause entirely new ones

It’s doing the right thing already and raising a nil object exception since you’re trying to invoke a method on a nil object which is nonsense