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

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Library, enhancement, P3)

Description

[Lars T Hansen]

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

[Edwin Smith]

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

Comment 2

[Lars T Hansen]

BTW, getQualifiedClassName(37) returns "int", which I find distressing.

Comment 3

[Lars T Hansen]

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

[Dan Smith]

Targeting to Future.  Useful capability. Push to QRB if you'd like to get into Brannan or Cyril.

Comment 5

[Lars T Hansen]

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.

Comment 6

[Dan Smith]

Bug 534012 covered improving describeType performance improvement but it was an optimization, not streamlining the API.

Comment 7

[Lars T Hansen]

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

Comment 8

[Edwin Smith]

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

Comment 9

[Lars T Hansen]

(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

[Edwin Smith]

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

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.