Re: Limited use for limited with?

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:09c36bd6-edfa-42bf-8f33-e91b0a9b0737@26g2000yqv.googlegroups.com...
On 5 Paz, 09:25, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> >No way. There are *many* Registers, meaning that a single object can
>> >be registered in several registries, not just one. Will you suggest
>> >passing an array of registries to the constructor? I hope not.
>>
>> This sounds like chaos, not a design.
>
>Let me guess: comp.lang.ada is the only group you are registered to, right?

Yes.

>And of course, you are subscribed to only one mailing list, right?

More than one of those.

>The possibility to register somewhere should be orthogonal to the
>number of registries. If I was able to subscribe to comp.lang.ada, I
>want to be able to subscribe to several other groups, too. It's not a
>chaos, it's an obvious result of decoupling.

But those things are registered by name (an simple text string), not 
registering an object. When you want to put something in lots of places, you 
have have an abstract way to refer to it.

Yes, you can use an access type to do that, but it is a lousy solution, 
because of dangling pointers, because it can't be stored, because there is 
no structure.

An example: in the Claw Builder, I tried to use access types to tie the 
various objects together. But it didn't work, because the structure is a 
graph of elements that are combined in various ways. There wasn't any way to 
restore the structure once it was saved to disk, saving the structure often 
saved elements multiple times, and similar problems. Moreover, the 
declarations all have to be placed in one giant package (a problem that Ada 
2005 tries to solve, but not very successfully). Eventually, I changed most 
of "links" to use names, which are then looked up in an appropriate index.

...
>> When you start with a poor design, it's not surprising you can only find
>> poor solutions...

>Translation: "I don't understand the purpose of the system, but the
>fact that my proposed solutions are not adequate is a sure proof that
>the original design must be broken." Is that right?

When I'm writing an Ada program, I want a design that can be expressed well 
in Ada. I don't much care whether it can be expressed well in some other 
language. And "well" includes safety against accidental misuse. Use of 
access types in object interfaces almost always compromises safety.

A design that can't be expressed well in Ada is a poor design (presuming you 
are planning to write the program in Ada). It would be the same for Java, 
C++, or any other programming language.

I personally think that callbacks are a poor fit for Ada (possibly because I 
started with Ada 83, where callbacks were impossible). It's not always 
possible to avoid them (i.e. GUI programming), but I don't think they should 
ever be introduced when there is an alternative. And if you do that, you 
don't need the "registration" in the first place. So I think a design using 
callbacks and registration is a "poor design". YMMV.

                                      Randy.