Re: Text terminal rendering design

H. S. Lahman wrote:
On the need for identifiers: keeping track of coordinates.
[...]
This also has to do with the disconnect about 2DArray semantics
that only became clear in the last message. This part of the
argument for identifiers was predicated on my assumption that
Symbols were only created for immediate display.

While that assumption would simplify the design, it is unfortunately
completely impractical. I worry that the reasons for it being
impractical have not been clearly expressed, despite my best efforts.
I'll make another attempt later in this post.

However, having Symbols around that aren't displayed is all the
more reason to keeping track of coordinates separately.

You are saying that the coordinates should be separate, but just to
be clear: What is your intended interpretation of 'separately' in
this case? Separate from each other? Not attributes of a Symbol
object? Separate from something else?

If they are not associated with a Symbol address, then how does one
keep track of them to access them during actual rendering?

Why wouldn't they be associated with a Symbol address? Is that
somehow connected to the issue of having Symbols that aren't
displayed? I haven't seen anyone suggest that coordinates and Symbol
addresses need to be in a 1:1 relationship.

Of course the coordinates are not going to be attributes of a Symbol,
but that is a huge step away from not associating Symbol addresses
with coordinates. When a Symbol is to be displayed an relationship is
instantiated between that Symbol and the Terminal. The specific
relationship dictates the coordinates.

I described that in the message you are replying to. If you see some
problem with it, it would be most helpful if you would point it out.

On the need for identity: are handles the way to go?
[...]
I am now getting the impression that the relationship is really
1:1 because you only provide one Symbol handle back to the client
to associate with the relevant Icon, even for conversions. If so,
that opens another can of worms for handle management: how do you
decide which Symbol address is passed back as the handle?

I think I make this clear by implication in another post, but just to
be sure I will explain it here. Symbols are data objects and to me
that means that the issue of which address I pass is irrelevant. The
only thing that matters with a Symbol address is the content of the
Symbol to which it points. So if I have two different address that
each point to to Symbols that hold identical data, then I can pass
either one and trust that the message semantics are identical. (Plus,
these are const addresses; the client is not going to be modifying
the Symbol.)

If you are wondering how I decide what the data should be, that is
equally easy. The data is the coded form of the symbol that the
client requested. The particular encoding depends upon the factory
that the client used to request the Symbol.

Whatever policy you settle on, you will have to have executable
code in your UI just to navigate properly whenever the client
provides a handle in a subsequent request.

I don't see what you think I would be navigating using the policy I
describe above. The data is pointed to directly by the address, which
is the simplest navigation possible.

On separating concerns of instantiation and data acquisition:
[...]
Then I missed something in your explanation. As I understood it,
if you did not need a conversion you invoked a different factory
method -- either in the same [SymbolFactory] subclass or in a
different [SymbolFactory] subclass -- to deal with a situation
like sourcing from the DB or getting data directly from the
client.

That seems to be correct.

Which? B-) Do you have multiple methods for different sources in
the same [SymbolFactory] subclass? Or do you have a unique
[SymbolFactory] subclass for each source?

I mean that SymbolFactory has methods for accessing a certain set of
standard sources, and to access other sources you need a method
somewhere else to produce your Symbol and then use a SymbolFactory to
get it into the desired encoding.

I am concerned that there may be misunderstanding because your
question offers a false dichotomy. To the question "Do you have
multiple methods for different sources in the same [SymbolFactory]
subclass?" the answer is certainly yes, but I also have classes for
accessing individual sources that are not handled by any of the
methods of SymbolFactory.

These other classes also produce Symbol objects to hold the data that
they access, but they are not subclasses of SymbolFactory because
SymbolFactory only has methods for dealing with the few standard
sources. In fact, I see no reason why the client could not
instantiate the Symbol objects itself if the client has symbol data,
since Symbol object are merely data objects.

This is munging together the overall semantics of conversion with
the particular problem of getting a given pile of data from
different sources. The data acquisition problem is much more
narrowly defined.

I am beginning to think that 'data acquisition' is not a matter for
the SymbolFactory or even the text terminal subsystem. When I think
of a SymbolFactory acquiring data, it is actually simply being given
data. It either gets the data from a Symbol object in a different
encoding that is given to it, or from the arguments of a construction
method that the client calls.

Even in my current design the SymbolFactory is not responsible for
actual data acquisition; it is only responsible for taking already
acquired data and converting it into the proper encoding. The actual
acquiring of data is a responsibility for the client.

On why symbols symbols are created without displaying them:
[...]
Just as we have been discussing, creating a symbol is a
nontrivial task involving conversions and DB lookups. It might
need to be done when time is available for such things. The
moment at which the screen is to be updated is frequently not
that time.

That's a whole other set of nonfunctional requirements that drives
a concurrent solution. That's an OOP problem, not an OOA/D
problem. Get the OOA/D right and the OOP implementation becomes
deterministic.

But aren't the quantifiers on the Terminal:Symbol relationship a
OOA/D issue? If that relationship is 1:* then each Symbol must be
displayed the moment it is instantiated. In that case, the OOP
implementation is deterministic, but it is deterministically broken.

Also, if it is not a OOA/D issue then why do you keep telling me that
a Symbol must be displayed when it is created?

I would not expect the client to know anything about creating
symbols, at least in the sense of object instantiation. I would
expect the client to think in terms of display ("Display Icon Z").
Why would the client care whether the UI creates all symbols at
startup or on an as-needed basis for display? That seems like an
implementation prerogative for the UI subsystem.

It does seem like that on the surface, but it is surely not. The UI
subsystem can create Symbols, but it has no way of knowing the
appropriate time to do it.

It could do it immediately before displaying the symbol; that would
be the simplest way, but that is horribly broken behaviour. It would
require that the subsystem delay the client's request to display the
symbol until after all the conversion and instantiation procedures
had been completed.

In almost every way we are not dealing with a real-time problem, but
this is one aspect that is real-time. I am trying to convey the idea
that it is unacceptable to do the conversion at the moment the client
requests the symbol be displayed. We are not allowed any unnecessary
delays at that moment. I wish I could find the words to make this
more clear. An application waits for user input for billions of
cycles, probably doing nothing at all, but when the user asks for
something the UI must react immediately, even if that means thousands
of symbols.

So when I say that the client cares about when Symbols are created, I
really mean it. I cannot accept any OOA/D that takes control of that
out of the hands of the client.

Creating all the symbols at startup is even worse, since it is
actually impossible unless we force the set of symbols to be finite
and known in advance. Both of the options which you consider to be
the only two options are completely unacceptable.

I am beginning to get the impression there are a bunch of other
requirements that may be relevant. B-)

I cannot see what those requirements could be. I have already talked
about how the client requires control over the moment at which symbol
conversion happens. Other than that there is just converting and
displaying symbols.

I am getting the impression that there is some suite of "generic"
Symbols that are always around from which the client selects
particular ones for display.

I cannot think of what those generic symbols could be. I expect that
your impression is not accurate. However, there is always at least
one generic symbol that represents a blank space. That is required
because each coordinate position must be in a relationship with a
Symbol when a Terminal is instantiated and the blank Symbol is that
Symbol.
.

Relevant Pages

  • Re: Text terminal rendering design
    ... The client is an application with need of a UI that works by ... what symbols it needs to display and the coordinates at which each ... In the case of most text terminals, a symbol is represented by a single ... complex conversion operations to put the symbol into a form that the ...
    (comp.object)
  • Re: Text terminal rendering design
    ... this would only be appropriate for a symbol that was instantiated purely for display compatibility. ... The only way I see is to have some separate notion of symbol identity that the client provides. ... available when each Icon is being constructed. ... What I thought you were representing was the fact that if a conversion is necessary, then there will be two Symbol instances in your UI software and you will provide both handles to the client to map to the relevant Icon. ...
    (comp.object)
  • Re: Text terminal rendering design
    ... Now I am how giving a reference to a Symbol to the client forces me ... deal with particular terminals. ... the client wants to do is display a single symbol, ... Conversion from one format to another is by ...
    (comp.object)
  • Re: Text terminal rendering design
    ... the client is not going to be modifying the Symbol.) ... The problem I am concerned about is giving the client one Symbol's address in a handle (when a conversion is involved) and the client has a subsequent request that applies to the other Symbol. ... For an instantiation problem this complex I think it would be highly desirable to use subclasses of for all instantiation so that there is a standardized way of handling instantiation and one can define context in the same way for all instantiations. ... If one decides to instantiate all the Symbols up front and then just select them for display all that changes is when SymbolFactory is invoked and mechanism for instantiating the display association just becomes a Find. ...
    (comp.object)
  • Re: Text terminal rendering design
    ... The client wants to later change the color and provides ... If the client is doing a multiple part conversion then the client ... On separating concerns of instantiation and data acquisition: ... A SymbolFactory always produces a Symbol of the same subclass. ...
    (comp.object)