From: William Coleda <[EMAIL PROTECTED]>
Date: Mon, 30 May 2005 09:56:22 -0400
Yeah, the PIR I showed was a bit of a hack based on current
functionality. Thinking about it more, I think we do need to have
true morphing between TclLists and TclStrings, especially we get to
true language interopability.
This is a problem with the current set of vtables, because while I
can extract the string value from a list using vtables, I don't think
there's a vtable for "extract list".
I don't think there can be, since there are probably multiple
definitions of what a "list" is.
. . . but:
set a "a b c"
lappend a d e f
needs to somehow get the list representation of the named variable.
So, of your four methods listed, I don't need "listToString", because
get_string works just fine for that. that leaves the two "...toList"
methods. Which I *can* add, but it means that if anyone wants to use
tcl from the another language, they are going to have support my PMC
interface... Isn't extending the basic interface the best way to
acheive this? (I realize that from the calling standpoint, a generic
METHOD looks like a vtable; but I'd like to use only standard
mechanisms for this, so Tcl isn't balkanized from the rest of the
languages)
Regards.
Two observations:
1. Seems to me that the two operations are "coerceToList" and
"coerceToString", and (as you point out) coerceToString is already what
get_string does. But (I am guessing) you require "Tcl list" behavior
from the result, e.g. a Lisp list wouldn't do, as it would be
represented incompatibly. If that is true, then people writing Tcl
calls from other languages may indeed have to deal with your TclList
PMCs -- that seems unavoidable. In that case, though, the other
operator really ought to be called something like "coerceToTclList".
2. If you write a coerceToTclList method on String, instead of/in
addition to one on TclString, then that ought to give you pretty
complete language interoperability.
Looking at the bigger picture, it is IMHO unreasonable to expect a
single standard mechanism across all languages, since each language is
going to have its own idiosyncratic semantic requirements. Instead,
each language needs to define its own standard interface for its own
needs, and then implement that interface on the most fundamental classes
possible, so that other languages pick up most of their interoperability
with the first language for free. In an ideal world, the other
languages wouldn't even need to be aware of the first language. In
reality, there will probably be some exceptions, which is fine; they
become the problem of the implementor of the other language.
In other words, I believe that these interfaces need to be (a)
decentralized, so that language implementors have maximum freedom to do
what they need, and (b) heritable from Parrot base classes, so that
interoperability with other languages is automatic.
-- Bob Rogers
http://rgrjr.dyndns.org/
