Thoughts From The Abyss

[Hans-Dieter.Dreier@Materna.DE]

--nzZsNPcrNH5q4lNPskxUliGADw5fMoIB
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>Hans-Dieter.Dreier@materna.de wrote:
>
>>> Hans-Dieter's transparent names are easily implementable as shorthands
>>> if we don't use prototyping, and hence don't require any extra features=
.
>> What do you mean by "prototyping" here?
>
>As in "an object-based approach where inheritance is perform by copying
>with update".  Hence this operation would be primitive.

Sorry, I still seem to not understand you fully. Maybe you see more in "tra=
nsparent names" than I do. For me, they are simply a means to modify the na=
me look-up process in the parser, ie the instance that binds an object to a=
 name). Once this binding has been done, there is no further difference bet=
ween a normal name and a transparent one. Everything you can do using trans=
parent names, you can do using ordinary qualification ("a.b") as well, only=
 less comfortable. =


>>> Type layout should never attempted before everything is known, since it
>>> prohibits elimination of unused methods, etc., which I suspect is a big
>>> cause of bloat in existing OOP systems.
>> What do you refer to?
>
>Say you wanted to eliminate a method because it's not used in a
>program.  Assume you're not loading/generating classes.  It can only be
>eliminated after linking, and this is rarely done.  A simple
>inter-module analysis could eliminate type methods by simply seeing if
>they're ever referred to.  Hence vtables would be smaller.  Actual
>instance fields being eliminated would shorten object layouts, but
>fields are harder, since you want to eliminate stuff that is written to
>but not read from, along with the assignments to them.

Currently, I wouldn't even bother to optimize such a case. See what you get=
: You save one reference per class (not per instance! since vtables are cla=
ss items), plus the method body, and no run time, at the expense of another=
 global optimisation pass after linking.

And if the method was statically dispatched to, this task could automatical=
ly done be GC anyway.

The other example (having a non-read-referenced instance item) should be pr=
etty seldom and should trigger a warning, rather.

But maybe there are better examples?

>From a programmer's point of view, if I can develop in a really modular,
>flexible way, it reflects on my software by a reduction in bugs, and
>quicker development/maintenance.  And if I can optimise even better than
>a standard C compiler lets me, it also reflects on my software that it
>is very fast and small.

True. And also, often underestimated: The smaller & clearer your source cod=
e is, the shorter is time-to-market. In this respect, IMHO C++ sometimes re=
sembles assemly language.
 =

>> Having the original state both unacceptable and modifiable is likely to
>> cause problems inside the editor. The user is in trouble as soon as he
>> decides to undo his changes in the middle of editing by restoring the
>> original state.
>
>Not really.  The view would support having that value, and allow
>changing to it, just not letting the user change to it.

Do you mean "letting the user change from it"?
Otherwise please explain.

>Hence an undo
>would just take you back to the unacceptable value and display that it
>is unacceptable.

That means it is unacceptable but allowed nevertheless?
As long as it's the original state?
This would do, but writing the user interface that needs to handle that wou=
ldn't become easier.

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--nzZsNPcrNH5q4lNPskxUliGADw5fMoIB
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a18627a.txt IA5 DX-MAIL X.400 User Agent=

--nzZsNPcrNH5q4lNPskxUliGADw5fMoIB--