Clearer errors to help debugging

#1

Hi, just a detail i noticed when trying to call the function .dispose() on a Bitmap ( not BitmapData ) : the compiler returns a very vague error :

“openfl.display.DisplayObject cannot be called”

Should be something like :

“openfl.display.Bitmap has no field dispose”

That would help debugging :}

#2

Yeah apologies for this

This is because we allow dynamic access to named children on display object containers, but to do it properly, we’ve had to enable it on DisplayObject, even though objects (like bitmaps) can’t have children.

Especially with SWF assets, it’s for things like mainView.border.menuContainer.menu.homeButton.x = 200

#3

Oh I get it, but dispose with () is a function, not a child anyways?

#4

Yes, but because we added implements Dynamic<DisplayObject> it thinks it might have a dynamic child DisplayObject if you reference an unknown field

#5

Same logic for TextField :

_tf.autosize = TextFieldAutoSize.CENTER;

returns : openfl.text.TextFieldAutoSize should be openfl.display.DisplayObject

… far from describing the actual error which is : autoSize and not autosize
( autosize is not a member of TextField )

God I hate Dynamic - most of the time -

Also i noticed, in the same logic, I can do :

_tf.mySuperDynamicProperty = new Sprite();

… even though there’s no point ever doing that.

So there’s no issue since i get the Dynamic inheritance here, just saying this is confusing and might repel newcomers to the haXe / openFL combo ( which I personally am very happy with ) :confused:

#6

… … this has bitten me so many times now… :frowning:

#7

Simple solution: add a flag to disable implements Dynamic<DisplayObject>. Then people who want to use the . operator still can, but people who don’t need it can get useful error messages.

2 Likes
#8

Now that SWF support is baked in, and named fields are propagated throughout (when using generate="true" on SWF) perhaps this will be less essential.

It is still important as an option, but I will try and see if the SWF improvements makes my SWF tests compile without dynamic access :slight_smile:

#9

I have just added support for -Dopenfl-dynamic, and enabled “strict mode” by default.

This means that no more confusion from implements Dynamic<DisplayObject> should occur, I also added implements Dynamic (in the event that you define dynamic mode) to openfl.errors.Error, as the Haxe core externs enable dynamic access there as well when not using “flash strict mode”

The new generation for known SWF types is better than implements Dynamic, In the event that you had multiple objects which known class names, the old system went from a known type (first level) to MovieClip (second level) to DisplayObject third level, meaning that anything other than core DisplayObjects fields (like x or y) required a cast. Now you can reference multiple levels deep, and so long as the parent has a class type, it will be known at compile-time, and will not use dynamic access.

I’m open to ideas if there is a better name for this define than “openfl-dynamic”, we basically now have Haxe’s “flash-strict” mode behavior by default, and have a way to disable.

Thank you

2 Likes
#10

You sir made my day. Also I think defaulting the flash-strict behavior makes total sense.