intoxopox

At the risk of dirtying this back-and-forth, I just wanted to say I've been enjoying the hell out of this discussion. I know all modernity screams modules over namespaces these days, and I even think I agree at the end of the day. However, I only started really learning JS and Typescript recently, having come primarily from ActionScript since its inception. With that background, I have secretly been partial to a hybrid of current module handling and namespaces. For me at least, having the library's user determine the alias rather than defaulting to a developer's root package/namespace invites confusion for multiple developers sharing code that use the same libraries. JS modules currently look not-ready-for-my-suborn-ways, with so many flavors and build dependencies, but they're getting closer for sure. Maybe it's just muscle memory, but I was quite fond of reverse domain name notation being sort of a forced rule for packaging/namespacing imports in languages like AS3. Looking forward to seeing how the dust settles... both in this thread and in future ECMAScript. As a side note, this article resonated with me: https://hackernoon.com/native-es-modules-ready-for-prime-time-87c64d294d3c

Thanks again, ivan! That works great. Now I can test for pointer with just Object.keys(someContainer.trackedPointers).length.

Ah... good looking out. I'll dig in later tonight. Thx!

I see. That makes sense. My particular use case is I have containers which have both sprite and graphic children. I was hoping to use something like containsPoint to see if mouse was still over any of the children. Further, I had abstracted this call in such a way that sometimes it would be called on one of the children and sometimes it would be called on the parent container. I can work around this ok, but just thought I had found a good reason to move the call to container and perhaps, in doing so, slightly improve the polymorphism. However, I see what you're saying.

Any thoughts on this request? I realize the implementation is different on graphics vs sprite-based, but it would be rad to have the method in Container for better polymorphism, and have it call the corrisponding implementation on graphic and sprite children.

Is there a good reason containsPoint method couldn't be moved down to Container and examine children, since it's already on Graphics, Sprite, Mesh, etc?

Did you ever have any success with getting webcam data?

Gotta say... I hope it comes back a lot sooner than that.

How about set a hitArea for the root container and listen for mouseleave or pointerleave.

Ah! https://github.com/jumpinjackie/jsdoc-typescript-plugin

Good question. New enough to Typescript (just over a month), I'm not really sure.

When do you guys think you'll have typescript definitions for v4? Not until official release, I suspect... but thought Id check.

Any updates on this?

For a line, using a rectangle is reasonable, but what about for thick complex curves? While they can be broken into multiple polygon fills, doing so comes at a considerable cost compared to just using quad and cubic curves.

If I create a Graphics object and draw just a thick line or curve in it, I can't seem to get any recognition of mouse interactions on that Graphic. Seems I have to use a beginFill and draw out a shape before mouse will interact. Anyone else experience this? Is there a work-around?