Make it possible to extract the vector's base type from the vector

NEW
Unassigned

Status

Tamarin
Library
P3
enhancement
6 years ago
6 years ago

People

(Reporter: Lars T Hansen, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

unspecified
Q2 12 - Cyril
Dependency tree / graph
Bug Flags:
flashplayer-injection -
flashplayer-qrb +

Details

(Whiteboard: PACMAN)

(Reporter)

Description

6 years ago
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

6 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

6 years ago
BTW, getQualifiedClassName(37) returns "int", which I find distressing.
(Reporter)

Comment 3

6 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.

Comment 4

6 years ago
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

6 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

Updated

6 years ago
Assignee: nobody → lhansen
Flags: flashplayer-qrb?
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Priority: -- → P3

Comment 6

6 years ago
Bug 534012 covered improving describeType performance improvement but it was an optimization, not streamlining the API.
(Reporter)

Updated

6 years ago
Depends on: 694290
(Reporter)

Comment 7

6 years ago
On Zerowing:
/display/flashruntime/2011+-+Add+getter+to+extract+base+type+from+Vector+type

Comment 8

6 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

6 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

6 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

6 years ago
Target Milestone: Q1 12 - Brannan → Q2 12 - Cyril
(Reporter)

Updated

6 years ago
Assignee: lhansen → nobody
You need to log in before you can comment on or make changes to this bug.