Some features should NOT include from GO/Java.

[Don]

Matthew Ong wrote:
> 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.

You're missing string mixins (which are totally different from string 
mixins).

> 
>> 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
> 
>