I found recent interest in Kotlin as a language, because the platform we develop for is Java 6 based and hence lacks any syntactic sugar the recent years brought to Java.
There's but one thing that makes it impossible to use Kotlin over Java in development, that is, the platform we develop for uses some reflection internally and requires members to be public. It won't work otherwise.
So, the bytecode generated from the Kotlin file in fact produces public getters and setters, the fields themselves yet remain private.
Is there a way to overcome this, so I get real public fields?
I am aware of the design failure that requires public fields, but the system is kind of a black box to us, we cannot change the fact that it has to be this way.
The annotation #JvmField should help you. It makes the Kotlin-compiler expose the property as a field on the JVM. See here: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/-jvm-field/
Related
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
I’m writing a small application based on FParsec.
Today, I’m looking for an opportunity to make a version for Compact Framework.
Apparently, it is not that simple to build FParsec sources for .NET CF. The FParsecCS library has unsafe code and some references to the types that are not available in CF. Namely, System.Collections.Generic.HashSet, System.Text.DecoderFallbackException, and more.
I’m wondering if there’s any way to make it built. Obviously, I’m trying not to alter the code as it would be hard to update when further versions of FParsec released.
I don’t really care about performance. If there is a generic CharStream that can be used instead of high-performance one you have, that would be quite sufficient.
Thank you for your help.
I don’t have any experience with .NET CF and never tried to make FParsec run on it. However, there’s a Silverlight version of FParsec, which might be a good starting point for a port to .NET CF. The Silverlight version builds on the LOW_TRUST version of FParsec, which doesn’t use any "unsafe" code. Hopefully, the stream size limitation of the LOW_TRUST version won’t be an issue for your application.
The easiest way to deal with the HashSet dependency probably is to implement you own simple HashSet type (based on a Dictionary) that implements the few methods that FParsec actually uses for its error handling. If the DecoderFallbackException is not supported, you can just comment out the respective exception handlers.
If you track your changes with HG, it shouldn’t be difficult to merge in updates to FParsec. Depending on how extensive the changes for .NET CF are, I could also include them in the main source tree for another conditional compiler symbol.
Just curious - are protocol buffers usable with F#? Any caveats etc.?
I'm just trying to answer this question myself.
Marc Gravell's protobuf-net project worked out-of-the-box with F# because it uses standard .NET idioms. You can use attributes to get serializing without having to write .proto files or do any two-stage compilation, or you can generate the necessary code from standard .proto files. Performance is good for .NET but a lot slower than alternatives like OCaml's built-in Marshal module. However, this library forces you to make every field in every message type mutable. This is really counter-productive because messages should be immutable. Also, the documentation leaves a lot to be desired but, then, this is free software.
I haven't managed to get Jon Skeet's protobuf-csharp-port library to work at all yet.
Ideally, you'd be able to serialize all of the built-in F# types (tuples, records, unions, lists, sets, maps, ...) to this wire format out-of-the-box but none of the existing open source solutions are capable of this. I'm also concerned by the complexity of these solutions: Jon Skeet's is 88,000 lines of C# code and comments (!).
As an aside, I am disappointed to see that Google protocol buffers do not specify standard formats for DateTime or decimal numbers.
I haven't looked at Proto# yet and cannot even find a download for Froto. There is also ProtoParser but it just parses .proto files and cannot actually serialize anything.
There isn't an F# specific one listed here, but there is an OCaml one, or there is a .NET "general" one (protobuf-net).
In all honesty, I simply haven't gotten around to trying protobuf-net with F# objects, in part because I simply don't know enough F#, but if you can create POCOs they should work. They would need to have some kind of mutability (perhaps even just private mutability) to work with protobuf-net, though.
If you are happy to generate a C# DTO and just consume that from F#, then protobuf-net or Jon's port should work just fine.
I'd expect both my own port and Marc Gravell's to work just fine with F#, to the same extent that any other .NET library does. In other words, neither port is written in a way which is likely to produce idiomatic F# code, but they should work.
My port will generate C# code, so you'll need to build that as a separate project for your serialization model - but that should interoperate with F# without any problems. The generated types are immutable (with mutable builders) so that should help in an F# context.
Of course, you could always take the core parts of either project and come up with an idiomatic F# solution too - whether you port the whole project to F# or use the existing libraries with an F# code generator and helper functions, or something like that.
I've heard a lot about the new/improved RTTI capabilities of Delphi 2010, but I must admit my ignorance...I don't understand it. I know every version of Delphi has supported RTTI...and I know that RTTI (Runtime Type Information) allows me to access type information while my application is running.
But what exactly does that mean? Is Delphi 2010's RTTI support the same thing as reflection in .NET?
Could someone please explain why RTTI is useful? Pretend I'm your pointy haired boss and help me understand why RTTI is cool. How might I use it in a real-world application?
RTTI in Delphi is still not quite as full-featured as Reflection in .NET or other managed languages, because it is operating on compiled code, not an Intermediate Language (bytecode). However, it is a very similar concept, and the new RTTI system in Delphi 2010 brings it a lot closer to reflection, exposing an entire object-oriented API.
Pre-D2010, the RTTI was pretty limited. About the only thing I ever remember doing with it was converting an enumerated type to a string (or vice versa) for use in drop-down lists. I may have used it at one point for control persistence.
With the new RTTI in D2010 you can do a lot more things:
XML Serialization
Attribute-based metadata (TCustomAttribute). Typical use cases would be automatic validation of properties and automated permission checks, two things that you normally have to write a lot of code for.
Adding Active Scripting support (i.e. using the Windows script control)
Building a plug-in system; you could do this before, but there were a lot of headaches. I wasn't able to find a really good example of someone doing this from top to bottom, but all of the necessary functions are available now.
It looks like someone's even trying to implement Spring (DI framework) for Delphi 2010.
So it's definitely very useful, although I'm not sure how well you'd be able to explain it to a PHB; most of its usefulness is probably going to be realized through 3rd-party libraries and frameworks, much the same way it works in the .NET community today - it's rare to see reflection code sitting in the business logic, but a typical app will make use of several reflection-based components like an Object-Relational Mapper or IoC Container.
Have I answered the question?
D2010's extended RTTI is a lot like C#'s reflection. It gives you the ability to get at any field of an object, or inspect its methods. This has all sorts of potential uses. For example, if you can read any field of an object, you can write serialization code that can work with any object. And the ability to inspect methods and obtain their name and signature makes a class much easier to register with a scripting engine.
To me, that's the primary advantage of extended RTTI: The ability to write code that works with any class by examining its members, instead of writing different versions of the same code over and over, tailored to each individual class.
Most people probably won't use it in a real world application.
The people who will use it are the framework builders. Frameworks such as DUnit make extensive use of RTTI.
With the new RTTI capabilities we should expect to start seeing more advanced frameworks and tools appearing, similar to what is available for .NET. These frameworks will revolutionise your development moreso than RTTI will on it's own.
RTTI in Delphi has always been important since version 1.0. Classic RTTI features include the "published" properties section of Classes, which allowed the Object Inspector and the component designtime features to work. For my purposes, I would often use Published class properties to allow for enumeration of those properties at runtime. To store things from my objects to disk, for persistence.
The Delphi 2010 RTTI extends this classic RTTI massively, so much so that you could be forgiven for thinking Delphi did not even have RTTI until delphi 2010.
I would say the #1 most useful applications of "The New RTTI" are (as several other answers already state) going to be in Frameworks written by the gurus, that:
Handle persistence to files or databases. Database and configuration or document saving/loading frameworks and components would use this under the hood.
Handle pickling/marshalling/encoding/decoding to and from various
over-the-wire formats, like JSON, XML, EDI, and other things.
Unit testing was mentioned by someone else (JUnit), but I think perhaps the same frameworks could be really handy for debug and error reporting tools. Given an object passed as a parameter, on the stack, why not have bug reports that can dump all the data that was passed along to a function that failed, and not just a list of functions?
As you can see, some creative people are likely to think of even more uses for this. You could say, that though it does not bring parity to .NET reflection (which another answer speaks more about), it does bring a lot of "dynamic language" features (Think of Perl, Python, JavaScript) to an otherwise strongly typed static-type systems world of Delphi.
For me, personally, extended RTTI gave a possibility to retrieve calling convention from the method pointer. However, currently, that code is under conditional directive, because i am not satisfied with it.
(Critics and suggestions on workarond with basic RTTI are welcome, tho)
Look for TMS Aurelius and you will see that RTTI Attributes are very useful in terms of creating an ORM DataBase Framework and XML Serialization into pure objects and the opposite too.
You are supposed to care because they put it on the box. Clearly they think that some people will care.
Whether you actually have a use for it is entirely dependent on the nature of your projects. Since you didn't have it before and don't understand why having it now is a benefit, this would suggest to me that you don't have a use for it. It's then up to you whether to spend the time researching the subject further in order to discover whether you might be able to find a use for it.
Whether that is the most productive use of your time in relation to your projects, again is something only you can know.
Is it possible to do Aspect Oriented Programming in Delphi? I would be interested in native support as well as third party solutions.
I don't have a specific problem I want to solve with AOP, but am simply interested in studying AOP.
AOP depends on two things:
The ability to inject additional code into an existing unit of code
A mechanism to place conditions on where code should be injected.
This is commonly referred to as code weaving. It is a specialization within the larger study of program transformation.
JIT compiled languages have more options for implementing code weaving than statically compiled programs because more information is retained in the bytecode/IL. They also support reflection, which offers the ability to manipulate code at runtime.
Delphi.NET and Prism have the same access to these capabilities as any other .NET language.
There are two AOP frameworks for Delphi Win32 that I'm aware of. The first is MeAOP, which has already been mentioned. The second is Infra. Both projects take a similar approach to AOP. They use a combination of RTTI and clever pointer manipulation to intercept method calls so you can run additional code before or after the method call. You define your cross-cutting feature as a subclass of the framework's AOP class. You register the methods you want intercepted by passing the method name as a string argument to the AOP framework.
Both frameworks are still actively developed and are actually larger in scope than just AOP. Unfortunately documentation is somewhat sparse (and in Infra's case mostly in Portuguese)
Another project attempted AOP through source code weaving back in 2004 with some success. Basically they built an aspect weaver on top of a general purpose program transformation tool called DMS and used it to inject code into delphi source files prior to compilation. Their aspect oriented language was primarily influenced by AspectJ.
http://www.gray-area.org/Research/GenAWeave/ has links to the original paper and presentation as well as some videos of the transformation process.
It may also be possible to use runtime code instrumentation to accomplish this as well. Its a technique used by some profilers to inject counters and stack traces into running code without modifying the original source. A similar technique could be used to inject crosscutting concerns into a statically compiled executable. The PinTool project is a good example of this.
ClassHelpers in the later versions of Delphi allow some very limited level of AOP type behavior. You can use ClassHelpers to inject behavior into other classes without descending from them. It allows overriding existing methods and then optionally calling that existing method.
The limitation is you must declare a ClassHelper for a specific class and it descendants. Additionally a class can only have one ClassHelper.
These are similar to Extension methods in C#.
The DSharp library features AOP:
https://bitbucket.org/sglienke/dsharp
More info can be found at: https://bitbucket.org/sglienke/dsharp
Also have a look at TVirtualMethodInterceptor.
It's in the RTL since Delphi 2010 and allows you to do OnBefore, OnAfter, etc. calls on all virtual methods on a class.
This call alone should cover must of what you need using Rtti, not weaving which is much faster than run-time weaving.