Closed Bug 629768 Opened 14 years ago Closed 13 years ago

ANI: opaque API for String, Namespace, etc (if necessary)

Categories

(Tamarin Graveyard :: Virtual Machine, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: stejohns, Unassigned)

References

Details

The existing APIs for String and Namespace (and probably a few other things) are reasonably well-encapsulated; do we need to wrap an abstraction layer around them, or can we just expose them as-is? (I'm tempted to add "for now, anyway", but we'd prefer to be able to implement ANI in a single pass, so if we don't do it now, it will probably never happen.)
I vote for "no encapsulation".
ditto
String is pretty entrenched but do we need to expose Namespace? Maybe the API should be purely in terms of Strings and Multinames? A cursory glance at player glue show's Namespaces being used a bunch in the debugger (could be moved into VM?) and otherwise its just a bunch of findPublicNamespace and getAnyPublicNamespace calls that probably could be hidden from the glue layer.
This might be a good time to discuss the value of the Stringp typedef. We want ANI to use GCRef<String> and GCMember<String> I think. Ie move typedef into the "internal" bucket and don't expose it.
The value of Stringp is negative at this point, it needs to be nuked from orbit.
The main reason to figure this out is that we probably only get one shot at this in the near-term future... if we go further down this road and wish we added encapsulation, well, tough. That said, I'm inclined to agree about String. I think Tommy's idea is worth investigating, though, if we can limit glue code to String+EncapsulatedMultiname it could simplify things a bit, I'll examine that and see how it looks.
Its worth double-checking the current interface (assuming we haven't done so already) to ensure that we don't 'leak' anything undesirable.
I think its pretty clear the ANI interface will expose String
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.