Class loses properties after method call

Mike_D · May 18, 2022, 3:49pm

@kevin_g how about just try this:

var obj as new Rect
dim ti as Introspection.TypeInfo = Introspection.GetType(obj)
dim mi() as Introspection.MethodInfo = ti.GetMethods
break

then take a look at the two operator_convert methods inside the mi() array - are they the same as mine? (One converts to REALbasic.Rect, the other converts to Nil )

kevin_g · May 18, 2022, 3:54pm

I’ve just ran that in a new project and there are no operator_convert methods in the mi() array.

Mike_D · May 18, 2022, 3:58pm

Impossible!
Could you perhaps be using any IDE plugins which have a Rect class that’s overriding the built in Xojo one?

My xojo 2022 R1.1 has the stock plugins:

MSSQLServerPlugin.xojo_plugin
MySQLCommunityPlugin.xojo_plugin
ODBCPlugin.xojo_plugin
OraclePlugin.xojo_plugin
PostgreSQLPlugin.xojo_plugin

Rick_Araujo · May 18, 2022, 3:59pm

Whatever is being done, properties can’t be silently erased, if they are, there’s a bug.

Mike_D · May 18, 2022, 4:07pm

@kevin_g I think you may be using an old version of Einhugur’s plugin? The new one contains a Rectangle class with an Inset method: EinhugurGeometry.Rectangle

Also, this used to be named “Rect” but was updated in version 9.6, see TypeLib

If I’m right, that explains why your compiler is behaving differently - you have a different Rect class than us…

kevin_g · May 18, 2022, 4:16pm

Thats it. Either Einhuger or MBS override Rect. Once I removed those plugins it compiled and I saw the same as everybody else.

My gut feeling is that this is working correctly.

var otherObj as OtherTestClass = obj
mIdentifier is lost during the conversion to the Rect superclass.

var backAgain as TestClass = otherObj
• mIdentifier can’t be restored as it doesn’t exist in otherObj.
• The Constructor can’t be called as the object already exists.

You might have to use operator_convert to handle this scenario the way you want it to.

kevin_g · May 18, 2022, 4:27pm

I think this could be working correctly.

The object is being converted to its superclass which means everything which makes the subclass different is lost. Converting it again can’t re-instate stuff that has been previously thrown away.

Torsten_Bernhard · May 18, 2022, 4:33pm

Compiles without error here.
Config:
Xojo 2022r1.1
MacOS 12.4
MacBook Pro 13" M1, 8GB
Plugins. See attached:

TimStreater · May 18, 2022, 5:14pm

FWIW, I have no plugins at all. Since I use none of the stock ones, I routinely move all stock plugins to an “Unused Plugins” folder, and my Plugins folder is empty.

Rick_Araujo · May 18, 2022, 5:18pm

Incorrect.

PropX = “123456” declared on a SubClass, once assigned to a SuperClass is lost, not erased.
That means that PropX is not accessible, instead of existing as PropX = “” in such superclass or being changed silently to “” at any point. And this is what is wrongly going on here.

Anthony_G_Cyphers · May 18, 2022, 5:34pm

As I said on the Feedback Case:

I would agree except we’re not attempting a conversion from ClassA to Rect to ClassB. We’re going from ClassA to ClassB, which — in my mind — should fail regardless of having a shared super.

Mike_D · May 18, 2022, 5:41pm

I’m on Team “It’s definitely broken”

if you replace Rect with a subclass cRect, the behavior is as expected, and it won’t compile.
if you futz around and add Operator_Convert() as Variant, you can get it to compile (which is legal, though an unwise thing to do). Then it will fail at runtime with an IllegalCastException (which is the correct behavior). Xojo never lets you cast a superclass into a subclass.
introspection shows that the Rect class seems to have a broken Operator_Convert which has a “nil” ReturnType. I’m pretty sure this is what’s causing trouble.

Rick_Araujo · May 18, 2022, 5:51pm

kevin_g · May 18, 2022, 5:52pm

You could be right.

ClassA to Rect as I mentioned would be classed as object slicing.

ClassA to ClassB is weird as but from Googling it looks like this is supported in some languages as I found this:

http://www.mathcs.emory.edu/~cheung/Courses/171/Syllabus/2-OOP/convert.html

In other words, Java permits you to perform the following assignment statements:
GeometricObject x ;
Circle y;

Convertion statements:
x = (GeometricObject) y;
y = (Circle) x; // This is “dangerous”, discussed later…

Mike_D · May 18, 2022, 5:59pm

Some are claiming that Operator_Convert() as Rect is firing and giving us a Rect.

But if you run this code, you see it isn’t true:

Notice how variable “r” is not a Rect but is TestClass - it was simply casted (which is legal, Xojo allows a superclass variable to refer to a subclass). It was not converted.

Rick_Araujo · May 18, 2022, 6:04pm

The correct way is

Class A:
  prop p
  prop q

Class B: Inherits A
  prop r

B contains p,q,r

A contains p,q

B can be moved to A satisfying p,q

A can't be moved to B because it does not satisfy r

So, for an A -> B it needs a proper B.constructor(A, r)

TimStreater · May 18, 2022, 6:07pm

But then what do you want to happen to r? If not silenty discarded then what?

Rick_Araujo · May 18, 2022, 6:09pm

A don’t know, don’t care, and don’t need r to function. B needs.

Think Animal and Dog

Animal contains name, and Dog inherits Animal and add the flag isFurry

If I have a Dog “Fido”, true, and move to animal, I have an animal “Fido”, and its ok. But if try to move fido to a Dog, I must say if it’s furry or not.

You mean A->B? A compiler error, not allowing a conversion assignment, then you must instantiate a new object supplying the missing parts to create a B from A. Probably you will write a proper constructor for it.

Torsten_Bernhard · May 18, 2022, 6:14pm

This is set theory, if I remember well

Rick_Araujo · May 18, 2022, 6:18pm

Basically yes, SQL also is deeply tied to set theory.