A few days ago, GFH introduced the two latest technologies in the QQ group (it should be a future technology): G # and CΩ, let the fox talk to the view of AOP. I also talk about my opinion today.
It is undeniable that the implementation of G # on the AOP is very strong. For example, the example in the original text is woven when the existing code is compiled. This also means that it can perform AOP to cut without changing the original code. It is said that it can also support running, it should be said to be a considerable Ideal AOP implementation. It solves a lot of problems in the current mainstream AOP technology.
For example, like AspectJ, it is designed, and a specific syntax is required. Dynamic woven in Nanning is relying on dynamic agents, and there is also a set of specifications. Not far from G # This is simple and beautiful.
Again CΩ is equivalent to a language built into O / R mapping. It provides a compile time check to database access, just like one of the data set by the aging agent class in Delphi in the first two months. But I am a very rough thing, depending on the code generation, but also manually generated. Many of the current O / R mapping are generated by tools. However, CΩ does more, it provides such an capability in the language level, which will automatically generate from the database from the database when compile (this part is guess from the example in the original text), which makes it The use will be simple.
There is also the automatic binding of XML, which is also equivalent to the XML Data Binding technology that I used to be used in the language level, that is, directly uses the XML as a Class. This is also a function I have been yearning for a long time.
But is it necessary to invent a language for a feature? What's more, the design ideas of these two languages are not portable. G # depends on the .NET runtime environment and IL compiler (after compiling the texture of the compiler must modify the compiler), CΩ is except these, except these, it also needs to rely on ADO.NET (and this phase ADO.NET also needs to be Supports versions of a specific function).
The temptation is very large, the risk is very large. ---- Because we only see the advantages they show, we will face what problems after investing in practical applications. We haven't known.
GIGIX also talked about CΩ yesterday. He believes that the strong type of CΩ makes it quite ugly, he tends to support the scripting language such as Groovy, this I have the same feeling. For some slight features special "creation" out of a new language, it is better to use a more powerful scripting language or dynamic language. Compared to scripting languages / dynamic languages, G # and Cω are nothing more than those functions that can be provided at compile, so there may be a small amount of performance improvement, but the cost of pay will be limitations and risks, especially under virtual machine platforms, this The performance improvement will be relatively limited.
