dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]Heteric idea about multutyer apps


From: Tomislav Sajdl
Subject: [DotGNU]Heteric idea about multutyer apps
Date: Tue, 15 Jan 2002 14:22:36 +0100

Would someone mind to comment this idea?

When you write some app, if you make it in tyers (it does not matter if
tyers are all in one exec. file or they are not), code is easier to
maintain, but it is less flexible. These things are matter of taste, but
anyway, many people still code all-in-one style. Realy, some things are then
faster to do.

In order to make tyered aplication to be written as easy as non-tyered, my
idea is to make compiler able to complile classical code into several
executables. Imagine some OO language: all objects marked with 'tyer1',
shell go to one executable, markde as 'tyer2' to another and so on. From
programmer's point of view, everything acts like one big exe. Compiler, of
course, has to make some RPC alike linking between separate tyers and
classical linking between calls in same tyer.

In order to achieve good performance, programmer will be able to experiment
where to put which object.

Programmer could forbid communication between some tyers, if he wants, etc.

Do you think that this could be a good way for people to migrate to tyered
architecture? This could be nice way to make distributed apps (I mean if
there are no tyers but parts of application running in separate
executables).

Problem:
This 'marking' could be done by multiple inheritence in languages where such
thing exists (every class in same tyer inherits same class).  That is good
thing because I don't like idea of changing language specification. But
marking has to be done in some different manner in Java, for example,
because AFAIK Java has no multiple inheritance.

Tomislav



reply via email to

[Prev in Thread] Current Thread [Next in Thread]