Component should be an interface, not a class
Closed this issue · 12 comments
E.g. velocity. I want it to be a Vector2:
class Velocity extends Vector2 { }
Since Velocity is already subclassing Vector2, it can't also extend Component. The only way around this is storing the vector inside the Velocity class. That's a level of indirection without value.
If Component was an interface, i can do this:
class Velocity extends Vector2 implements Component { }
I see no downside to this, Component has no methods or fields anyways.
Slower access to interface methods, up to 6% on the JIT version of Android according to google: http://developer.android.com/training/articles/perf-tips.html#Myths
That's onpy relevant if you call interface methods, which does not apply
here. Component has no methods.
On Jun 7, 2015 2:38 AM, "pakoito" notifications@github.com wrote:
Slower access to interfaces, up to 6% on the JIT version of Android
according to google:
http://developer.android.com/training/articles/perf-tips.html#Myths—
Reply to this email directly or view it on GitHub
#170 (comment).
Also, the 6% hit was only relevant on Dalvik without JITing, so < 2.1.
There are no such systems in use anymore.
On Jun 7, 2015 2:41 AM, "Mario Zechner" badlogicgames@gmail.com wrote:
That's onpy relevant if you call interface methods, which does not apply
here. Component has no methods.
On Jun 7, 2015 2:38 AM, "pakoito" notifications@github.com wrote:Slower access to interfaces, up to 6% on the JIT version of Android
according to google:
http://developer.android.com/training/articles/perf-tips.html#Myths—
Reply to this email directly or view it on GitHub
#170 (comment).
ART doesn't use JIT, but there're no comments on the documentation about perf hits.
You're right about the methods, bad overlook :P
ART has comparable non-overhead to Dalvik JIT for itf methods. On mobile,
can link to ART source if you insist. Would rather get back to OT.
On Jun 7, 2015 2:48 AM, "pakoito" notifications@github.com wrote:
ART doesn't use JIT, but there're no comments on the documentation about
perf hits.You're right about the methods, bad overlook :P
—
Reply to this email directly or view it on GitHub
#170 (comment).
OT then, sorry for derail.
This will break absolutely every Ashley project but I get and share your point.
Will probably implement and document the changes. I actually thought about this a while back.
Could you introduce some more breaking changes with that? Such as replacing entity id's with UUID?
Could you introduce some more breaking changes with that? Such as replacing entity id's with
UUID?
java.util.uuid is not supported out of the box in GWT. There are some workarounds apparently but nothing standard. We could look into it. What is the problem with long? It is extremely unlikely you're going to have problems with it.
I think UUID is to heavyweight tbh. As for breaking changes: you are the
judge. I believe this breaking change to be trivial. End users only have to
change extends to implement.
On Jun 7, 2015 7:50 PM, "David Saltares" notifications@github.com wrote:
Could you introduce some more breaking changes with that? Such as
replacing entity id's with UUID?java.util.uuid is not supported out of the box in GWT. There are some
workarounds
https://groups.google.com/forum/#!topic/google-web-toolkit/0Iwgv-4wmsc
apparently but nothing standard. We could look into it. What is the problem
with long? It is extremely unlikely you're going to have problems with it.—
Reply to this email directly or view it on GitHub
#170 (comment).
What is the problem with long? It is extremely unlikely you're going to have problems with it.
Two randomly generated UUIDs are (almost) never equal, which can make it useful for implementing client/server protocols. Rather than adding a setId method to Entity, the UUID would be passed to addEntity. What are the actual use cases for the current entity id's?