I'm terribly tired of checking all my arguments for null, and throwing ArgumenutNullExceptions when they are.
As I understand it, C# 4.0 enables some design by contract constructs. Will it be possible to specify that a method will not accept null arguments in C# 4.0?
Also, is there anything I can do in the meantime (maybe an attribute?) to avoid this monotonous task of checking for null and throwing?
You can create a NotNull<T> generic class that helps, but there are some side effects. See Robert Nystrom's blog post.
Rick Brewster describes a good solution for concise, declarative style parameter checking in this post,
http://blog.getpaint.net/2008/12/06/a-fluent-approach-to-c-parameter-validation/
Avoids use of reflection (drawback of DbC) and creates no overhead for non-exceptional code path.
Like how he uses extension methods to allow what appears to be instance method calls on null objects. Very clever bit of coding IMO.
If you are sold on DbC, Google Spec# and PostSharp.
Not sure about native DbC constructs in C# 4.0 but Microsoft is going to release cross-language Contracts library.
You can download version for MSVS2008 here.
As an alternative to the already given answers, it is worth looking into the Null Object design pattern.
The essence of this design pattern is that once the "null object" is created, there is no further need to perform any checks for null and the methods of the null object implement the behavior desired whenever a null (otherwise) would have been passed vs a reference to a "real object".
This design pattern does not depend on C# 4.0 and in fact can be easily implemented in almost any OO programming language.
I have just started using Code Contracts its a new feature in C# 4.0 you need to download an addin from MS to allow you to see it in your project settings. Details here ->
http://research.microsoft.com/en-us/projects/contracts/
Related
Cycript is a console based application that is a blend of Objective-C and JavaScript. Cycript is very useful for dynamic analysis of iOS applications.
If you write any methods or the complete ipa with Swift is it still possible to hook the application on a jailbroken device? Or is Swift safe like "native C" Code on iOS ?
I'm not really familiar with Cycript but I have a little understanding of the Swift compiler.
Swift code will be more resistant to hooking but it should not be completely impossible. NSObject subclasses and Swift classes that are declared #objc should be as accessible as Objective-C code. Pure Swift code, especially in optimised builds would be harder to inject code into because they are often statically dispatched and in many cases will actually be inlined into the calling code.
Where code hasn't been inlined it may may be possible to patch the functions in memory themselves to jump to an alternative function but it wouldn't be as easy as just modifying function tables.
Where key functions have been inlined it may be possible to find and modify each usage if common patterns of code that could be identified and if the function is long enough it may be posible to patch in a jump to an alternate version but this would get really quite tricky.
I am new to Haxe.
When I try to convert the following line from C# to Haxe using CS2HX:
Interlocked.Increment(ref this.fieldName);
I get error from CS2HX:
ref/out cannot reference fields, only local variables
Now this makes me wonder - are Interlocked functions at all supported by Haxe - ?
Since I certainly would want to use Interlocked on fields and not on local variables.
Are there any alternative options besides using a lock?
Haxe should now have support for ref/out arguments extended so that fields are accepted too. The updates are in Git. Thanks go to #Waneck!
https://groups.google.com/forum/?hl=en#!topic/haxelang/3E-N93qoU38
CS2HX needs separate modification for that upgrade.
Maybe I will do that later myself, at the moment I have no time for that. I will post a comment here when I have updated CS2HX myself or find out that somebody else did it.
An alternative idea that came from that forum is using one-element array, I think that is pretty good too. Certainly better than using locks.
Is it a must to know Groovy to start learning Ofbiz? The one book i can find is for version 4 of ofbiz and it uses Beanshell. I don't know if later versions of ofbiz have added support for groovy.
Objective: to create workflows as necessary.
Thanks.
EDIT: Found this. From what i understand, one can use any compliant Java scripting language.However, Groovy will be supported OOTB. (Groovy is not just a scripting language, but it is one of the roles)
Later versions have added support for Groovy.
AFAIK, you can still use Beanshell if you want
No, you shouldn't, unless you want use not java but groovy to develop something - e.g, event, service - for OFBiz.
If you familiar with java, that's enough for you to read and understand the source code written in groovy, and it's enough in most case to write some simple in-line groovy script used in OFBiz.
"Know groovy", it's nice-to-have but not must to "start learning OFBiz".
Groovy is used a lot in screen actions, which is the data preparation code that is part of generating UI output. There is a lot of code in the project like this.
It can also be used to implement services and request events (used for processing input), and is a popular tool for custom extensions to OFBiz even though not used a lot in OFBiz itself.
As stated in other answers if you know Java it's easy to read most Groovy code (some closure syntax can be confusing at first), but it's worth learning about more to reduce code size and effort, and make your code cleaner and easier to maintain. In other words, Groovy has a lot of extensions beyond plain Java that are very useful, especially for business logic in applications like those built with Apache OFBiz.
As a case in point, the next generation framework based on the ideas in OFBiz (Moqui Framework, www.moqui.org) is written largely in Groovy and supports Groovy for everything whereas OFBiz also uses JUEL for expressions (and even Beanshell still in a couple places). I should note that both frameworks support a number of other scripting languages for business logic if you have other strong preferences, but it is nice to standardize on one so that developers have less to learn and can more easily work with existing business logic and (as applicable) framework code.
First, I have to say that I really like Groovy and all the good stuff it is bringing to the Java dev world. But since I'm using it for more than little scripts, I have some concerns.
In this Groovy help page about dynamic vs static typing, there is this statement about the absence of compilation error/warning when you have typo in your code because it could be a call to a method added later at runtime:
It might be scary to do away with all of your static typing and
compile time checking at first. But many Groovy veterans will attest
that it makes the code cleaner, easier to refactor, and, well, more
dynamic.
I'm pretty agree with the 'more dynamic' part, but not with cleaner and easier to refactor:
For the other two statements I'm not sure: from my Groovy beginner perspective, this is resulting in less code, but in more difficult to read later and in more trouble to maintain (can not rely on the IDE anymore to find who is declaring a dynamic method and who is using one).
To clarify, I find that reading groovy code is very pleasant, I love the collection and closure (concise and expressive way of tackle complicated problem).
But I have a lot of trouble in these situations:
no more auto-completion inside 'builder' using Map (Of Map (of Map))
everywhere
confusing dynamic methods call (you don't know if it is a typo or a
dynamic name)
method extraction is more complicated inside closure (often resulting in code duplicate: 'it is only a small closure after all')
hard to guess closure parameters when you have to write one for a method of a subsystem
no more learning by browsing the code: you have to use text search instead
I can only saw some benefits with GORM, but in this case the dynamic method are wellknown and my IDE is aware of them (so it is more looking like a systematic code generation than dynamic method for me)
I would be very glad to learn from groovy veteran how they can attest of these benefits.
It does lead to different classes of bugs and processes. It also makes writing tests faster and more natural, helping to alleviate the bug issues.
Discovering where behavior is defined, and used, can be problematic. There isn't a great way around it, although IDEs are getting better at it over time.
Your code shouldn't be more difficult to read--mainline code should be easier to read. The dynamic behavior should disappear into the application, and be documented appropriately for developers that need to understand functionality at those levels.
Magic does make discovery more difficult. This implies that other means of documentation, particularly human-readable tests (think easyb, spock, etc.) and prose, become that much more important.
This is somewhat old, but i'd like to share my experience if someone comes looking for some thoughts on the topic:
Right now we are using eclipse 3.7 and groovy-eclipse 2.7 on a small team (3 developers) and since we don't have tests scripts, mostly of our groovy development we do by explicitly using types.
For example, when using service classes methods:
void validate(Product product) {
// groovy stuff
}
Box pack(List<Product> products) {
def box = new Box()
box.value = products.inject(0) { total, item ->
// some BigDecimal calculations =)
}
box
}
We usually fill out the type, which enable eclipse to autocomplete and, most important, allows us to refactor code, find usages, etc..
This blocks us from using metaprogramming, except for Categories which i found that are supported and is detected by groovy-eclipse.
Still, Groovy is pretty good and a LOT of our business logic is in groovy code.
We had two issues in production code when using groovy, and both cases were due bad manual testing.
We also have a lot of XML building and parsing, and we validate it before sending it to webservices and the likes.
There's a small script we use to connect to an internal system whose usage is very restricted (and not needed in other parts of the system). This code i developed using entirely dynamic typing, overriding methods using metaclass and all that stuff, but this is an exception.
I think groovy 2.0 (with groovy-eclipse coming along, of course) and it's #TypeChecked will be great for those of us that uses groovy as a "java++".
To me there are 2 types of refactoring:
IDE based refactoring (extract to method, rename method, introduce variable, etc.).
Manual refactoring. (moving a method to a different class, changing the return value of a method)
For IDE based refactoring I haven't found an IDE that does as good of a job with Groovy as it does with Java. For example in eclipse when you extract to method it looks for duplicate instances to refactor to call the method instead of having duplicated code. For Groovy, that doesn't seem to happen.
Manual refactoring is where I believe that you could see refactoring made easier. Without tests though I would agree that it is probably harder.
The statement at cleaner code is 100% accurate. I would venture a guess that good Java to good Groovy code is at least a 3:1 reduction in lines of code. Being a newbie at Groovy though I would strive to learn at least 1 new way to do something everyday. Something that greatly helped me improve my Groovy was to simply read the APIs. I feel that Collection, String, and List are probably the ones that have the most functionality and I used the most to help make my Groovy code actually Groovy.
http://groovy.codehaus.org/groovy-jdk/java/util/Collection.html
http://groovy.codehaus.org/groovy-jdk/java/lang/String.html
http://groovy.codehaus.org/groovy-jdk/java/util/List.html
Since you edited the question I'll edit my answer :)
One thing you can do is tell intellij about the dynamic methods on your objects: What does 'add dynamic method' do in Groovy/IntelliJ?. That might help a little bit.
Another trick that I use is to type my objects when doing the initial coding and remove the typing when I'm done. For example I can never seem to remember if it's .substring(..) or .subString(..) on a String. So if you type your object you get a little better code completion.
As for your other bullet points, I'd really need to look at some code to be able to give a better answer.
I'm writing my master thesis, which deals with AOP in .NET, among other things, and I mention the lack of support for replacing classes at load time as an important factor in the fact that there are currently no .NET AOP frameworks that perform true dynamic weaving -- not without imposing the requirement that woven classes must extend ContextBoundObject or MarshalByRefObject or expose all their semantics on an interface.
You can however do this with Java in the JVM thanks to ClassFileTransformer:
You extend ClassFileTransformer.
You subscribe to the class load event.
On class load, you rewrite the class and replace it.
All this is very well, but my project director has asked me, quite in the last minute, to give him a list of frameworks (and associated languages) that do / do not support class replacement. I really have no time to look for this now: I wouldn't feel comfortable just doing a superficial research and potentially putting erroneous information in my thesis.
So I ask you, oh almighty programming community, can you help out? Of course, I'm not asking you to research this yourselves. Simply, if you know for sure that a particular framework supports / doesn't support this, leave it as an answer. If you're not sure please don't forget to point it out.
Thanks so much!
EDIT: #ewernli
I'm asking about (2).
In C# you can indeed emit code at run-time and create new classes dynamically, but they are new classes, they do not replace an existing class. What I'd like to do is to transform the class at load-time, like you can do in Java with the ClassFileTransformer.
About modifying a method's signature: yes, you're right. I should have mentioned that in my case I don't want to modify the class' interface, but rather the content of its methods.
Your answer was really helpful. Thank you :)
Are you asking about (1) true class replacement at run-time, or (2) facilities to transform the class when it's loaded or (3) languages which support dynamic class loading ?
Java support dynamic class loading with ClassLoader, transformation with ClassFileTransformer, but no true class replacement.
I'm not sure for C#, but I think you can emit code at run-time and create new class dynamically, so you can achieve (3) and probably (2).
True class replacement is mostly supported only by dynamic language, e.g. Smalltalk, Ruby, I guess Python and a few others. This requires the transformation of the instances of the class to match the new shape. They usually initialize the new fields to nil if the class changes.
AFAIK, dynamic languages ported to the JVM make extensive hacking of ClassLoader to support class replacement at run-time. For JRuby, see A first taste of invoke dynamic to get more pointers how they do it now, what's problematic and how the upcoming invokedynamic might help.
This is not offered in statically typed languages because of the complication with the type system. If a method signature change in a class, other existing classes already loaded might not necessary comply with the new method signature which is not safe. In java you can however change a method as long as the signature is the same using the Java Platform Debugger Architecture.
There have been some attempt to add this feature to Java, and/or statically typed languages:
Runtime support for type-safe dynamic Java classes
Supporting Unanticipated Dynamic Adaptation of Application Behaviour
A Technique for Dynamic Updating of Java Software
This paper provide a general overview of related problems
Influence of type systems on dynamic software evolution
Not sure exactly if that address you initial question, but these pointers might be interesting for your thesis anyway.
The Java language doesn't support class file replacement. The JVM exposes the feature via the classes you mention. Therefore all languages which have been ported to the JVM can take advantage of it.
Erlang supports hot code swapping, and if you are looking also for theoretical frameworks that model dynamic class updates, you can take a look at the Creol language (interpreted).
Objective-C's runtime library supports dynamic construction and registration of classes, lazy method registration and "method swizzling" by which method implementations can be switched at runtime. Previous versions supported "Class swizzling" by which a class could be substituted for another at runtime, but now method swizzling is used instead. Here's the reference doc.