Re: Text terminal rendering design

Responding to Guild...

We have so many subthread tangents going that it is difficult to keep track of context, so I am going to start using headings...

On the need for identifiers: keeping track of coordinates.

One is that one needs to associate coordinates with a symbol.
Presumably the client tells you that when asking for a symbol to
be displayed. It would be tempting to put the coordinates in
[Symbol] as attributes.


That is not tempting me in the slightest. I think that would be a horrible thing, actually! If I had coordinates as attributes of Symbol then each symbol could only be displayed at one point on the screen. That alone is more than enough reason not to do it, without even considering the other reasons.

As I indicated subsequently, this would only be appropriate for a symbol that was instantiated purely for display compatibility. Even then, there would be problems with holding the data until that symbol actually got created.

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.

However, having Symbols around that aren't displayed is all the more reason to keeping track of coordinates separately. If they are not associated with a Symbol address, then how does one keep track of them to access them during actual rendering? The only way I see is to have some separate notion of symbol identity that the client provides.

On the need for identity: are handles the way to go?

The client has some client class Icon of objects that are in a
1:* relationship with a symbol, i.e., Icon objects must always
have an associated symbol. If that symbol is represented
according the the client's view of the symbol, it is immediately
available when each Icon is being constructed. However, if the
client uses an address handle it must wait for the SymbolFactory
to finish instantiation and that time could leave an Icon in an
inconsistent state where an asynchronous process could access it.

That 1:* relationship is an example of where that mapping can get
messy. Why does the client need to know that there might be two
different [Symbol] objects needed to process the display request?


I don't know the answer. It seems to me that the client does not need to know that. I should not be expected to devise a reason for something that I feel is unnecessary.

The context here is whether handles are viable for the client to use as identity. My argument is that the 1:* relationship between Icon and Symbol is not desirable /because/ there is no reason for it in the client context. (This may be another disconnect over the semantics of 1:*; see below.)

I was referring to the possibility of having two alternative designs, yours and mine. I was trying to explain why yours was better than mine. In each design the client only has to deal with one representation.

I seem to have missed that intent. B-( I thought you were still arguing that handles were OK.

That is purely a problem of the way that your UI software needs to
deal with particular terminals. At its level of abstraction all
the client wants to do is display a single symbol, Icon.


In my example, Icon was not a symbol. Icon was a class of objects where each object needed a symbol. Presumably each object also represents the semantics that are associated with that symbol. My point was only that Icon was in a 1:* relationship with Symbol and any class that had a 1:* relationship with Symbol would have worked just as well.

1 R1 *
[Icon] ----------------- [Symbol]

That relationship says that every member of the Icon set has _at least_ one member of the Symbol set associated with it. 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.

I am arguing that is bad because the client really should not know that you need to instantiate two Symbols for the same Icon in some situations.

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? 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.

On separating concerns of instantiation and data acquisition:

I am not sure what you are suggesting this as an alternative to.
My current design does almost exactly this, but instead of having
DataAcquisitionStrategy get data, it gets a Symbol object and we
skip the SymbolFactory step. The rest is entirely the same,
including allowing someone or anyone to check the terminal type
and invoke a converter.

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?

If a different method is used for direct, DB, or symbol sourcing,
then the caller has to understand the context of where the
initialization data comes from. If combinatorial subclassing is
used, then instantiating the relationship requires applying the
rules for terminal type and data acquisition at the same time. In
addition you need to encode a unique method for every combination
of data sourcing and terminal type.


That is true as well. Conversion from one format to another is by nature a combinatorial problem, it seems. When I say 'conversion' I mean converting a DB format to the terminal format just as much as I mean converting a Symbol object from one encoding to another.

There is only one way to limit the size of the combinatorial explosion and my current design supports it.

You have to convert to an intermediate data format and accept an almost inevitable loss of information. The intermediate format allows the conversion to proceed in two steps and avoids the effort of writing a complete set of conversion procedures. This is supported in my design simply by using one factory to get a Symbol in the intermediate format and then another factory to convert to the final format.

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. For a particular terminal you need a symbol representation that has certain attributes. You have three possible sources for those attribute values: client data in a message data packet; a DB record in the correct format; or an existing Symbol.

In all three cases there is an implicit assumption: the source has all the data that is needed to instantiate the Symbol that the terminal can eat; DataAcquisitionStrategy just knows where to go to get it. [In retrospect I am pretty sure I didn't make this assumption clear for the delegation. B-(]

If the client message or DB record doesn't have all the data or the right semantics for the data, then you have to provide a conversion to get to a Symbol that does have the right data and semantics. The DataAcquisitionStrategy just knows how to copy data from different sources. At most it knows about relatively minor conversions like ASCII/unicode. It is an entirely different problem to create a Symbol that has the right data. IOW, DataAcquisitionStrategy only accesses a Symbol when a conversion had to be performed.

[Creating a Symbol as output of the conversion seems fairly generic (i.e., independent of the conversion details). But there is no reason why the conversion process could not directly write the dataElementN attributes of [DataAcquisitionStrategy] without ever invoking getData().]

On why symbols symbols are created without displaying them:

A Symbol is only added to the R1 collection when it needs to be
displayed according to the client's UI needs. Therefore, a Symbol
can be created at any time before it needs to be displayed and it
can be added to the R1 collection many and various times after
being created.

That confirms my suspicions of a disconnect over the semantics of 2DArray. Why would the UI create a symbol if it wasn't going to be
displayed immediately?


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. [I.e., that's why god invented full code generators for translationists like me. B-)]

That only makes sense if one wants to create all the /available/
symbols displayable by a terminal at startup.


I don't think it matters when the client wants to create the symbols. If the client agrees with you and wants to make them all at startup, that is no business of the text terminal subsystem. If the client wants to do it at various times during the running of the application, that is also harmless.

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.

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

0..1 R1 displays *
[Terminal]----------------------[Symbol]
To allow for Symbols that are not displayed. If that is the
source of our misunderstanding then I strongly apologize.

That will be true if you instantiate Symbols at startup (or for
other reasons than display). As I indicated above, that is a
disconnect we had.


We have been discussion instantiation of Symbols for other reasons than display, haven't we? Symbols are often an intermediate step in a conversion process, and those Symbols are not in any relationship with a Terminal.

Sure, but that has been temporary within the scope of a request to display a particular symbol. Once one has the terminal-compatible version in hand (i.e., the one participating in the R1 relationship above), the intermediate version would presumably go away.

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. If so, that's fine but what are the requirements that drive that? If they are nonfunctional, they aren't relevant to the functional design. If they are functional, then they may impact what we have been talking about (at least as far as relationship conditionality is concerned).

And I cannot imagine why you see it as impossible for the client to want symbol creation to be at a time other than startup or display.

I can't see why the client would care about Symbol instantiation in the UI at all.

[If the client can create new symbols that end up in the DB, then the client will have some notion of creation. But that notion will be quite different than instantiating Symbol objects in memory. IOW, it is more likely to be in terms of Icons ("Create Icon Z") or storage ("Save Icon Z").]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.