Re: Text terminal rendering design

Responding to Guild...

On the need for identifiers: keeping track of coordinates.

[...]

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?

They need to be owned by some other entity than Symbol. I think we are agreed on that. Since they depend on the client's selection for display, one needs an object that captures the notion and scope of selection, which 2DArray does.

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.

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 example suppose the handle you always give back is for the "natural" Symbol that is initially created, which might not be augmented for background color needed for a graphic terminal rendering. The client wants to later change the color and provides that handle in a message requesting the color change.

Since the color is irrelevant to the Symbol whose address identity the handle captures, your code will have to know that it needs to access the other Symbol to honor the request. To do that it will need some mechanism to navigate to it from the handle's Symbol.

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.

Wow. I afraid don't like the sound of that at all; it seems really messy. For an instantiation problem this complex I think it would be highly desirable to use subclasses of [SymbolFactory] for all instantiation so that there is a standardized way of handling instantiation (i.e., polymorphic access to a single generalization) and one can define context in the same way for all instantiations (i.e., one always instantiates the same relationship).

Presumably the [SymbolFactory] subclasses are mapped 1:1 to different symbol subclasses. Then the source of the initialization data is orthogonal and one has a choice between providing that substitution as separate methods or as combinatorial subclasses of [SymbolFactory].

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.

Right. [SymbolFactory] just instantiates from a given pile of data. Where the pile is located shouldn't matter to it.

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.

That's fine if it is a simple computational conversion on an attribute-by-attribute basis. It would normally be the factory's job to do that sort of conversion. But some of your conversions seem more complicated than and I would push for delegation of the responsibility.

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.

Separation of concerns applies to OOA/D construction too. B-) The relationship instantiation only identifies who the participants are in a collaboration. The dynamics of the collaboration is something else again (When one navigates the relationship). There is nothing to prevent displaying each of the Symbols on the *-side at quite different times. That will be driven by the dynamic requirements

It is not an OOA/D issue because techniques for things like heap optimization are routine in OOP and it is easy to map to them. 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(id).

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'm not telling you that. I thought that was how you described the problem. As I understood the problem, Symbols were created on an as-needed basis for display. The notion that Symbols might already exists before a client's display request only came up in the last couple of messages.

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.

There is something missing here because I can't follow this argument. What you have described is a performance requirement for your UI software. That's fine and resolving it may require anticipatory Symbol creation.

What I don't follow is why the client cares anything about how you resolve that requirement. The client just wants a symbol displayed and tells you when to do that. It is up to your software to do whatever is necessary to do that efficiently.

IOW, resolving the performance requirement determines when Symbols need to be created in memory. There are any number of techniques for doing that ranging from instantiating them all at startup to some sort of fancy LRU scheme. Which scheme is best will depend on things like resource limitations, but I don't see how the client fits into the decision.

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.

Actually, I don't think you have. All you have said is that in your design the client has control over when the conversion happens. (BTW, this is the first time you have mentioned even that.) What I am pushing back on is why that should be the case because at least superficially it seems to trash subject matter cohesion.

There may, indeed, be a problem space constraint that is being addressed, in which case there isn't much one can do about it. I just want to be sure it isn't a previous design decision that seemed to be a good idea at the time.

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.

I was thinking in terms of something like base Symbols for the ASCII character set that the client might select from.

BTW, what is a 'terminal' in your world? In particular, does you application ever need to instantiate more than one terminal at a time or more than one terminal in a session?


*************
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



.

Relevant Pages

  • Re: implementing roles in OOP......
    ... relationship instantiation from relationship navigation. ... every Element subclass. ... The Client provides the Visitor reference when it invokes ... >>encapsulated as knowledge responsibilities in a single class. ...
    (comp.object)
  • 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
    ... 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)
  • 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)