[
Lists Home |
Date Index |
Thread Index
]
Leigh Dodds writes:
> Oh, ok if you must :)
Oops, did my bias show?
> Well my helper routine just makes it *appear* as if the element is being
> renamed. In fact a new element is created, and the children of the
> original element moved over. Probably not very efficient, but it was
> good enough at the time.
That's an implementation detail as far as I'm concerned, but means
that all references to the old node are (effectively) invalid. Python
generally approaches implemenation with a "we're all adults here"
attitude, so typically allows setting of all attributes by any code;
it takes real work to protect an attribute. It's then just a matter
of how concerned the implementor is with "readonly" designations in
the spec (and we see both ends of the spectrum in practice... heck,
I've implemented both ends for the DOM!). As long as the DOM is
written in Python (rather than for Python but in C or some other
language), it's incredibly difficult to prevent Python code from
modifying the underlying values that an implementor may use to to
support tagName or any other DOM attribute.
> I wasn't aware of that. Interesting. Presumably this is to allow custom
> DOM implementations (e.g. for SVG) to substitute their own implementations?
> Is this feature used in practice?
Yes; I would be surprised if many HTML DOMs don't do that! I've
certainly considered using the technique in other situations as well
-- it seems very reasonable.
> Seems like there are various ways this functionality could be
> retained, but still allow renaming to take place. Worse case
> scenario is that a rename ends up creating a new kind of object,
> but this could still be transparently handled by the DOM impl I
> think.
Yes, kinda. It would be very easy in Python, and I suspect
relatively painful in Java. My first shot at it would be be to use
proxies, but it's hard to proxy arbitrary derived classes in Java
(consider that the actual interface is extended, and you want the
proxy to behave as the specialized interface).
> Thinking about it, if this feature *is* to allow different classes
> for differently named elements, then presumably this is to allow
> these classes to have additional behaviour. You're going to need a
> cast or similar to get an alternate reference, so this could be
> handled just as well by delegation I think. Or have I gone all
> Java-centric again :)
Very! I have a proxy type for Python which can have it's referent
changed, and the behaviors of the proxy change accordingly; it can
lose and gain attributes easily. I'd expect this wouldn't be hard
with JavaScript either -- a proxy object which wraps the actual object
is a pretty fundamental thing in the JavaScript model (or it was the
last time I read the spec; not recently).
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
|
