[erlang-questions] Fear and Loathing in Programming La La Land

[Jan Burse]

ok@REDACTED schrieb:
> Actually, conciseness just plain doesn't enter into this discussion
> at all.  Whether you say
>     t = new X(ping: 1, pang: 2, pong: 3, pung: 4)
> or
>     t = new X(); t.ping(1); t.pang(2); t.pong(3); t.pung(4);

Thank you for clarifying this.

> What is at issue is
>   - exposing incompletely initialised objects
>   - the lack of any distinction between 'setters for initialisation
>     only' and 'setters that can be called at any time', resulting
>     in anything you want to be initialised by name in the
>     create-set-call antipattern being vulnerable to revision by
>     ANYONE at ANY TIME even in another thread.

I just noticed that the above questions only deal
with the client view of a object/service whatever.

On the other hand good code / maintainable code etc..
is a question that does not only deal how well an
interface works for a client, but also how easy
it is to maintain the implementation side of
an object/service.

But lets turn back to your client view question.
I have already mentioned that when objects
are concurrently used for tasks, that there is
no need for synchronization. So the problem of
vulnerability by another thread does not exist.

How comes that task objects don't need
synchronization? Well, in that the object is
only created inside a thread and only used
by this thread for a limited amount of time,
and in a way that the object does not leak
to other threads.

Take as a very typical example Web pages that
use some "beans" to access and integrate various
data sources. The typical server code looks as
follows:

    void getBookList() {
        out.println("<table>");
        BookListBean bean = new BookListBean();
        bean.setDate(..);
        bean.setAuthor(..);
        bean.list();
        while (bean.next()) {
           out.println("<tr>");
           ...
           out.println("</tr>");
        }
        bean.close();
        out.println("</table>");
    }

The Web container will receive multiple requests
for book lists. So the above code will be executed
concurrently. Nevertheless the BookListBean need
not be synchronized. Since only one thread at a
time is using an instance of the class BookListBean.
It is created on the fly and then left to the GC
when it is not used anymore.

The above pattern is found in many Web frameworks.
It was initially there in JSP with the bean
directive. But it can be used for any tasks you
want. It is Peter Coads moment-interval approach.

This approach can also be used to compose
moment-intervals. Asssume for example that
information about a book authors is fetched from
a different data source. This can easily be
done as follows:


    void getBookList() {

        BookListBean bean1 = new BookListBean();
        ...
        bean1.list();
        while (bean.next()) {
             AuthorInfoBean bean2 = new AuthorInfoBean();
             ...
             bean2.list();
             ...
        }
        bean1.close();
    }

Again no problem whatever with concurrent access
to the beans bean1 and bean2, since they are solely
owned by the thread that executes the web request
getBookList.

But maybe the above moment-interval stuff is outdated
with the advent of googls map reduce. Did not yet
look into the question whether alternate web request
serving techniques might result in extra vulnerability.

Maybe Richard can make a case where the sychronization
is a problem. i.e. where a thread does go on, and
expose an object to another thread in a fashion
where setters would especially pose a problem.

I think the solution is to declare whether
a class is design to be used concurrently or not.
And then in the extreme to deliver synchronized
and unsynchronized versions, just as is with
Hashtable and HashMap in Java.

But when we have synchronized and unsynchronized versions
of class we see that all methods are affected. Not
only setters. In the case Hashtable and HashMap there
are even hardly any setters , so the normal protocol
of the object is affected anyway.

Bye