OT: Programming Expansibility

[Jeffery via Digitalmars-d]

It kinda dawned on me that there are two major issues with 
programming:
[Internal code = code created by you/me, User code = code created 
by the user to use our code]

1. Extensibility -

When we write code that will be used(by anyone), essentially it 
is wrapped in another layer of indirection. Each time, each 
"flaw" in the reduces the code flexibility and hence 
extensibility suffers.


2. Dependency Levels -

When we create explicit dependencies of dependencies then the 
flaws become magnified. Since the number of "cross-references" is 
generally exponential. (e.g., old school programming basically 
ignores this factor, which is why it is so hard to maintain).

---------

Example: [Assume no null objects and everything public]

Internal:

class Mine
{
    void foo();
}

User:

class Yours
{
     Mine m;
}

----

Yours y;
y.m.foo();  <-- a 2-level dependency

This is hard to maintain!!!!

Since no changes can be made to the interface of Mine.(we could 
obviously make it much worse by having parameters for foo)

class Yours
{
    Mine m;
    void foo() { m.foo; }
}

y.foo(); <-- much better, since if m changes, it won't break 
anything that depends on Yours since foo will exist. Simply 
updating Yours.foo is enough to work with m is enough. This is 
basic oop of course.


---

But if one logically extends this, would we not want remove 
multiple indirections? This creates a sort of chain of 
dependencies rather than a complex structure of them. (sort of 
like chain mail vs a chain)

Again, this is basic oop.

But going further:

What would we not want to make all indrections only one level 
deep?

e.g.,

No, Hers.His.Theirs.Ours.Yours.Mine.foo();

Each level creates a serious dependency issue if Ours.foo is 
changed. We have to deal with 6 levels of dependencies scattered 
across an untold number of real dependencies. It is an 
exponential increase in complexity!
(every line of that uses some form of indirection to get at foo 
creates a new flaw)


But there seems to be a solution!!

Never allow one to have more than one level of indirection.

E.g., Hers.foo(); (foo is not mine foo but a wrapped version).


Having more than one level reduces extensibility, makes code 
harder to maintain, etc.

But essentially this requires wrapping all the methods at each 
level. This is linear rather than exponentially but still a lot 
of typing. (but ultimately not more than the typing that one has 
to do to fix the flaws that each level of indirection creates)


What I'm thinking is that it would be better to expose wrappings 
for every member of every field and all the members of every 
field object. (this, of course, is exponential too)

This allows us to always use only one level of indrection(e.g., 
Yours.foo rather than Yours.Mine.foo).

D can already do this using OpDispatch!!! (this allows us to do 
it programmatically)

IDE's could do this also by simply providing default wrappers to 
for all cases. (sort of like implement interface in Visual 
Studio, but done automatically... or reflection could be used, 
etc)


The problem, of course, is name collisions and name 
pollution(sort of related).

Is there a solution?

Possibly a new symbol is needed to prevent both name collisions 
and allow for such capabilities? e.g., Yours.Mine`foo. In this 
case, Mine`foo is not Mine.foo in the standard sense, but simply 
calling a member of Yours called Mine`foo.

But there is a better way?

If compilers only allows one level of indirection, then 
Yours.Mine.foo makes sense. The first . is standard member 
access. The Mine.foo part is not another level of indirection of 
simply name disambiguation. (it's like Mine`foo)

In this case though, we'd have effectively two levels of 
indirection and not really solved the problem.

But if we can "alias" Mine inside Yours then we have made some 
headway.

e.g.,

class Yours
{
    alias Mine = NotMine;
    void Mine.foo();    // actually calls NotMine.foo
}

Of course D can already do this too!!

Ultimately we are trying to gain the "dependenciness" of a flat 
hierarchy with the separation that nesting provides.

D seems to provide some great mechanisms to allow one to treat 
things as a semi-flat hierarchy but still have the indirection 
capabilities.

Is there more that can be done? It seems that most languages give 
the programmer full freedom to die in quicksand(you can choose as 
little and as much levels of indirection you want to use in any 
place). D allows some ability for the programmer to create a 
systematic way to deal with the problem but still requires the 
programmer to deal with this issue(e.g., we would still have to 
implement OpDispatch and use aliases, etc)

Is there a more consistent approach? A language that is naturally 
designed around preventing dependency explosion yet not 
compensating with requiring a large amount of boilerplate code(in 
which the compiler would actually take care of)?


Basically most languages have virtually no consistent view on the 
issue. D has the tools but they feel more like "add ons" after 
the fact rather than a natural part of the language that is 
designed to help the programmer with such issues.