Another solution: Define a read-only interface. Derive a read/write
interface. Implement the latter. Tell folks that for public API purposes,
they should generally use the former, to guard against stepping on their
fingers.
(Or make the write calls a separate interface and have the concrete cla
You know, I guess I am not sure what the big deal is... We pass
objects with read/write interfaces on them around all the time
to code that we don't expect to modify them and we don't consider
them all to be inherently broken. What is so special about this
case ?
-Glenn
|
| To: [EMAIL PROTECTED]
|
| cc:
[EMAIL PROTECTED] wrote:
Well, the consensus between Sandy, Lisa and I is that (a) we kinda wish
this hadn't come up at all, but now that we've gone this far, (b) go ahead
and change it; we'll slip the release until Monday. This'll give a weekend
to run tests and make sure no subtle bugs got intr
|
| cc:
|
|
Andy Clark wrote:
[EMAIL PROTECTED] wrote:
Neither I nor Sandy feel sufficiently strongly about the matter of the
XMLLocator setters to contest it. Since you want it changed, are you
in a position to change it?
Okay, I've made the change.
Crap. Late last night I realized that there is a
prob
On Thursday, 01/23/2003 at 02:18 PST, Andy Clark <[EMAIL PROTECTED]> wrote:
> Joseph Kesselman wrote:
> > That'd work, I guess. Though I don't quite see why this wouldn't want
to
> > be part of the basic pipeline design.
>
> Do you have any specific interface ideas?
I did, and I *think* I advanc
[EMAIL PROTECTED] wrote:
Neither I nor Sandy feel sufficiently strongly about the matter of the
XMLLocator setters to contest it. Since you want it changed, are you in a
position to change it?
Okay, I've made the change.
However...
I've noticed that the copyright information in the
source fil
[EMAIL PROTECTED] wrote:
Neither I nor Sandy feel sufficiently strongly about the matter of the
XMLLocator setters to contest it. Since you want it changed, are you in a
position to change it?
Yes, I can make the change. I haven't searched the
code, yet, but I don't expect there to be any cases
|
| cc:
|
[EMAIL PROTECTED] wrote:
* XMLLocator
I was surprised to find setters on this interface.
I know that we want a fully read-write framework but
this doesn't make much sense. Does the parser jump
around in the stream when the application sets the
line and/or column number?
No, but maybe some com
Joseph Kesselman wrote:
That'd work, I guess. Though I don't quite see why this wouldn't want to
be part of the basic pipeline design.
Do you have any specific interface ideas?
--
Andy Clark * [EMAIL PROTECTED]
-
To unsubscri
Hi Andy,
Now that I've had a chance to think about these issues more, and talk about
them with the other folks here in Toronto, here's a more complete response
than I gave yesterday:
> * Augmentations
> Why do we use the method name "removeAll" in
> other places but use "clear" on this interface
>> I'd
really like to see XNI support the concept of a hierarchy of
>> pipelines -- that is, I'd like to see a pipeline be usable as
an XNI
>> component
>We could do this through a utility class. Or did
>you have something else in mind?
That'd work, I guess. Though I don't quite see why
this w
Joseph Kesselman wrote:
I'd really like to see XNI support the concept of a hierarchy of
pipelines -- that is, I'd like to see a pipeline be usable as an XNI
component, rather than having to reach into the pipeline to find the
first/last components and much with them to connect them to the rest
I'd really like to see XNI support the
concept of a hierarchy of pipelines -- that is, I'd like to see a pipeline
be usable as an XNI component, rather than having to reach into the pipeline
to find the first/last components and much with them to connect them to
the rest of the world.
(If this ha
Hi Andy,
Only one thing jumps out at me here as needing immediate comment; I'll
think about the other issues and respond later.
> * XMLDocumentHandler
> The document source setter and getter should be
> moved to the XMLDocumentFilter interface. The end-
> points don't need to know their source -
I think that we need to resolve the following issues
before declaring XNI final and version it at 1.0:
* Augmentations
Why do we use the method name "removeAll" in
other places but use "clear" on this interface?
* NamespaceContext
What about the question regarding whether this should
be an inte
18 matches
Mail list logo
