Some features should NOT include from GO/Java.

[Matthew Ong]

On 5/16/2011 10:37 PM, Matthew Ong wrote:
> Hi All,
>
> The reason I am starting this thread is to gather some valid/experience that
> people do not like about using Go or even Java. Naturally D-programming might
> not wants to repeat the same error.
>
> Java:
> 1) Swing API --- The inheritance tree is too deep. New OO encourages
>     flatten object (1-2 level inheritance) for easy memory management from the
> JVM/GC.

> 2) final --- does not protect the content of the LinkedList/Hashmap.
>     I think immutable keywords managed that? Informed me if I am wrong.

> 3) Do not have keywords to allow conditional compilation like version in D.
version(Windows)... does it

> 4) Threads are rather heavy and synchronization, that is why people introduced
>     kilim. Something like the fiber-thread concept.
I read somewhere that it was written that threads. From what I can see 
in some weaknesses of JVM and claimed to be addressed by Go(shown on a 
video) about using multi-threads for multi-core CPU. There is no built 
in Java standard Thread Pool Manager at the JVM level but left to the 
J2EE container to implements. J2EE is sometime too complex to junior 
developers and writing our own container is a hard thing.

I have seen in languages like prolog and perhaps others, that the thread
are managed with options, perhaps some sort of built in library that 
does seemed to allow management.

http://www.swi-prolog.org/man/threads.html
clicked on 8.7.2.

> 5) No marco-preprocessor like in C #define, when the limitations of the
>     syntax is met. Sometime, that allows
mixin with template does address some of this issue I supposed. That 
does allow me to define up to level of content of a class but is not 
class itself.

mixin template AType(T){ // but does not seems to allow me to inherit 
ClassC this level.
private:
    T value;
public:
    this(){...}
    void print(){...}
}

class ClassB : ClassC{ // ClassC Inheritance/Interface must only be done 
at this level?
    mixin AType!(string); // content
}

Perhaps I am missing something here.

> 6) No void* to allow passing of function pointer into any method to be
>     called. That can be tricked:
>     by using
>     interface F1<R,P>{
>      R func1(P p1);
>     }

> 7) No closure...Or lamda J.

> 8) No clear IPC like COM+, DCOM. Need to do networks sockets with full stack
> overheads.

C# does has that ability by nature. Java has to make use of JCom to 
bridge within windows. But RMI from java makes use of network sockets 
full stack. Since D is system level API, I am wondering if there is a 
solution?


> 9) GUI inter-component messaging is complex and can only do share memory.
>     I hope that is defined with D. Yes, there MVC, but how to inter-comm
>     without exposing too much info, there should be a way to do in-memory JMS
>     model.



> GO:
> 1) No while/do-while/foreach... ONLY for loop.
> 2) Only Public/private scope... That claim is semi-true.
>     It allowed to have method introduction to a library defined type. And
>     allows user of that type to use the new method without knowing.
> 3) there is no auto promotion of data type even when it is safe.
>     int does not go into long automatically. byte to int...etc (Aiks!!!)
>
> Both,
> There is no way to have a centralized Exception handling routine that
> allow routing of error message&  filtering for both language like in the JSP.
> JSP.
>
> Over all, those are modeling issues that I do see.
>
> Matthew Ong
> ongbp at yahoo.com


-- 
Matthew Ong
email: ongbp at yahoo.com