Closed
Bug 685460
Opened 13 years ago
Closed 6 years ago
Make it possible to extract the vector's base type from the vector
Categories
(Tamarin Graveyard :: Library, enhancement, P3)
Tamarin Graveyard
Library
Tracking
(Not tracked)
RESOLVED
WONTFIX
Q2 12 - Cyril
People
(Reporter: lhansen, Unassigned)
References
Details
(Whiteboard: PACMAN)
From Grayson Lang: "We desperately need a method to tell what the type of a Vector is. Currently there is no easy and reliable mechanism (outside of string manipulation) to find what a Vector contains. (It is possible if it isn't empty to grab a value from the Vector and look at its type, though a Vector can have a Vector as its content, which makes it pretty hacky)." This does seem like an arbitrary limitation. At a minimum a vector type should have (for example) a .parameterType property that would yield the class object describing the type parameter; more generally we could imagine a .parameterTypes property that yields an array of the parameter types for generic types in general (forward-looking). It's still not clear to me how to obtain the vector type given a vector (any more than we can obtain the type of any given value). getQualifiedClassName() gets us some part of the way there but is not enough.
Comment 1•13 years ago
|
||
> (It is possible if it isn't empty to grab a value from the Vector and look
> at its type, though a Vector can have a Vector as its content, which makes
> it pretty hacky)."
That of course won't distinguish Number, int, or uint from each other.
Reporter | ||
Comment 2•13 years ago
|
||
BTW, getQualifiedClassName(37) returns "int", which I find distressing.
Reporter | ||
Comment 3•13 years ago
|
||
Of course the "constructor" property, if not actively hidden by the object, can be used to extract the class object. Indeed (new <int>[1,2,3]).constructor returns the Vector.<int> class object. So if the class object has a parameterType property then we should be able to get "int" from it.
Targeting to Future. Useful capability. Push to QRB if you'd like to get into Brannan or Cyril.
Flags: flashplayer-qrb+
Target Milestone: --- → Future
Reporter | ||
Comment 5•13 years ago
|
||
Actually a PACMANesque item because "describeType is slow" is also a common complaint (I need to dig up that bug but we should not make people go thru string manipulation for simple introspection). Asking for a Brannan target, this is not a lot of work.
Flags: flashplayer-qrb+ → flashplayer-qrb?
Whiteboard: PACMAN
Target Milestone: Future → Q1 12 - Brannan
Assignee: nobody → lhansen
Flags: flashplayer-qrb?
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Priority: -- → P3
Bug 534012 covered improving describeType performance improvement but it was an optimization, not streamlining the API.
Reporter | ||
Comment 7•13 years ago
|
||
On Zerowing: /display/flashruntime/2011+-+Add+getter+to+extract+base+type+from+Vector+type
Comment 8•13 years ago
|
||
Is there rationale for using a getter, rather than a reflection function in the family of describeType()? (no strong opinion either way, just noting the precedent).
Reporter | ||
Comment 9•13 years ago
|
||
(In reply to Edwin Smith from comment #8) > Is there rationale for using a getter, rather than a reflection function in > the family of describeType()? (no strong opinion either way, just noting > the precedent). Well, rationale... sort of: describeType et al seem to generally return string values naming types, not Class objects representing types. As reflection facilities go they are pretty weak. Also, the precedent I am looking to is "constructor": to get the type of an object, ask for its constructor. To get the constituents and attributes of a type, ask the type for them. It's actually kind of curious and non-OO that describeType is a global function rather than a method on a type: an accident of history?
Comment 10•13 years ago
|
||
(In reply to Lars T Hansen from comment #9) > (In reply to Edwin Smith from comment #8) > > Is there rationale for using a getter, rather than a reflection function in > > the family of describeType()? (no strong opinion either way, just noting > > the precedent). > > Well, rationale... sort of: > > describeType et al seem to generally return string values naming types, not > Class objects representing types. As reflection facilities go they are > pretty weak. > > Also, the precedent I am looking to is "constructor": to get the type of an > object, ask for its constructor. To get the constituents and attributes of > a type, ask the type for them. sure, I buy that. > It's actually kind of curious and non-OO that describeType is a global > function rather than a method on a type: an accident of history? Putting the value in an argument position instead of receiver position was slightly less restrictive, and it allowed reflection apis to go elsewhere in the namespace from the everyday api's. Not strong reasons, but IIRC thats what the thinking was.
Reporter | ||
Updated•13 years ago
|
Target Milestone: Q1 12 - Brannan → Q2 12 - Cyril
Reporter | ||
Updated•12 years ago
|
Assignee: lhansen → nobody
Comment 11•6 years ago
|
||
Tamarin is a dead project now. Mass WONTFIX.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 12•6 years ago
|
||
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
You need to log in
before you can comment on or make changes to this bug.
Description
•