Search Results

Search found 24043 results on 962 pages for 'private methods'.

Page 52/962 | < Previous Page | 48 49 50 51 52 53 54 55 56 57 58 59  | Next Page >

  • What are various methods for discovering test cases

    - by NativeByte
    All, I am a developer but like to know more about testing process and methods. I believe this helps me write more solid code as it improves the cases I can test using my unit tests before delivering product to the test team. I have recently started looking at Test Driven Development and Exploratory testing approach to software projects. Now it's easier for me to find test cases for the code that I have written. But I am curios to know how to discover test cases when I am not the developer for the functionality under test. Say for e.g. let's have a basic user registration form that we see on various websites. Assuming the person testing it is not the developer of the form, how should one go about testing the input fields on the form, what would be your strategy? How would you discover test cases? I believe this kind of testing benefits from exploratory testing approach, i may be wrong here though. I would appreciate your views on this. Thanks, Byte

    Read the article

  • Running Java Program linking to thirdpary library (java -jar) issue ( Multiple methods tried )

    - by bamachrn
    This issue is related to running a Java program (jar) dependent on thirdparty jar library even after setting classpath and trying so many other methods by reading articles in Internet. I want to use a thirdparty Pack1.jar (it is not a part of jvm) as dependency of my programme. I do not know where the Pack1.jar file could be in the deployment machine and I want the deployer to specify the path for the thirdparty libraries I have tried the following alternatives in vain Setting the java.class.path programatically String class_path = args[0]; System.setProperty("java.class.path",class_path); Here I am assuming that deployer would supply the classpath as first argument while running the program Setting the CLASSPATH env_var to locate the thirdparty directory While running, using the classpath option java -classpath /path/to/Pack1.jar -jar Pack2.jar I think this would not work because documentation says that classpath is ignored when program is run with "java -jar" Setting the java.ext.dirs programatically. Setting the java.library.path programatically. I do not want to specify the Class-Path in manifest because that takes only relative path and I do not know where the thirdparty library would be kept in deployment machine But I am unable to get the jar running. How can I fix this problem any help please.

    Read the article

  • Call AsyncTask methods from another class/service (callbacks?)

    - by TiGer
    Hi, I was wondering if it's possible to call specific methods defined within the AsynTask class from another class and/or service ? In my specific case I have a Service playing some sounds, but the sound is selected from a List with available sounds... When a sounds is selected it is downloaded from my home server, this takes some time (not much, let's say around the 3-4 seconds, the sounds/effects aren't big in size)... So my problem at the moment is that I have a service to play those sounds, and when I select one I wanted to show a progressdialog... The way (if I understood correctly) is to use an AsyncTask, but the only thing the AsyncTask will do is telling my Service to play a specific sound from my server... So there is no "callback" from the service to the Asynctask... How can I achieve that ? How can I call a running AsyncTask, which sits in another class, and tell him all work is done and thus he can stop showing the ProgressDialog ? Or am I over-engineering it and there are other ways ? Thanks in advance...

    Read the article

  • [Scala] Using overloaded, typed methods on a collection

    - by stephanos
    I'm quite new to Scala and struggling with the following: I have database objects (type of BaseDoc) and value objects (type of BaseVO). Now there are multiple convert methods (all called 'convert') that take an instance of an object and convert it to the other type accordingly. For example: def convert(doc: ClickDoc): ClickVO = doc match { case null => null case _ => val result = new ClickVO result.x = doc.x result.y = doc.y result } Now I sometimes need to convert a list of objects. How would I do this - I tried: def convert[D <: MyBaseDoc, V <: BaseVO](docs: List[D]):List[V] = docs match { case List() => List() case xs => xs.map(doc => convert(doc)) } Which results in 'overloaded method value convert with alternatives ...'. I tried to add manifest information to it, but couldn't make it work. I couldn't even create one method for each because it'd say that they have the same parameter type after type erasure (List). Ideas welcome!

    Read the article

  • Problem with class methods in objective c

    - by Rajashekar
    Hi Guys i have a tableview controller like so, NSString *selectedindex; @interface ContactsController : UITableViewController { NSMutableArray *names; NSMutableArray *phonenumbers; NSMutableArray *contacts; DatabaseCRUD *sampledatabase; } +(NSString *) returnselectedindex; @end in the implementation file i have +(NSString *) returnselectedindex { return selectedindex; } when a row is selected in the tableview i put have the following code. selectedindex = [NSString stringWithFormat:@"%d", indexPath.row]; NSLog(@"selected row is %@",selectedindex); in a different class i am trying to access the selectedindex. like so selected = [ContactsController returnselectedindex]; NSLog(@"selected is %@",selected); it gives me a warning: 'ContactsController' may not respond to '+returnselectedindex' and crashes. i am not sure why. i have used class methods previously lot of times , and never had a problem. any help please. Thank You.

    Read the article

  • value types in the vm

    - by john.rose
    value types in the vm p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Times} p.p2 {margin: 0.0px 0.0px 14.0px 0.0px; font: 14.0px Times} p.p3 {margin: 0.0px 0.0px 12.0px 0.0px; font: 14.0px Times} p.p4 {margin: 0.0px 0.0px 15.0px 0.0px; font: 14.0px Times} p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Courier} p.p6 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Courier; min-height: 17.0px} p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Times; min-height: 18.0px} p.p8 {margin: 0.0px 0.0px 0.0px 36.0px; text-indent: -36.0px; font: 14.0px Times; min-height: 18.0px} p.p9 {margin: 0.0px 0.0px 12.0px 0.0px; font: 14.0px Times; min-height: 18.0px} p.p10 {margin: 0.0px 0.0px 12.0px 0.0px; font: 14.0px Times; color: #000000} li.li1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Times} li.li7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Times; min-height: 18.0px} span.s1 {font: 14.0px Courier} span.s2 {color: #000000} span.s3 {font: 14.0px Courier; color: #000000} ol.ol1 {list-style-type: decimal} Or, enduring values for a changing world. Introduction A value type is a data type which, generally speaking, is designed for being passed by value in and out of methods, and stored by value in data structures. The only value types which the Java language directly supports are the eight primitive types. Java indirectly and approximately supports value types, if they are implemented in terms of classes. For example, both Integer and String may be viewed as value types, especially if their usage is restricted to avoid operations appropriate to Object. In this note, we propose a definition of value types in terms of a design pattern for Java classes, accompanied by a set of usage restrictions. We also sketch the relation of such value types to tuple types (which are a JVM-level notion), and point out JVM optimizations that can apply to value types. This note is a thought experiment to extend the JVM’s performance model in support of value types. The demonstration has two phases.  Initially the extension can simply use design patterns, within the current bytecode architecture, and in today’s Java language. But if the performance model is to be realized in practice, it will probably require new JVM bytecode features, changes to the Java language, or both.  We will look at a few possibilities for these new features. An Axiom of Value In the context of the JVM, a value type is a data type equipped with construction, assignment, and equality operations, and a set of typed components, such that, whenever two variables of the value type produce equal corresponding values for their components, the values of the two variables cannot be distinguished by any JVM operation. Here are some corollaries: A value type is immutable, since otherwise a copy could be constructed and the original could be modified in one of its components, allowing the copies to be distinguished. Changing the component of a value type requires construction of a new value. The equals and hashCode operations are strictly component-wise. If a value type is represented by a JVM reference, that reference cannot be successfully synchronized on, and cannot be usefully compared for reference equality. A value type can be viewed in terms of what it doesn’t do. We can say that a value type omits all value-unsafe operations, which could violate the constraints on value types.  These operations, which are ordinarily allowed for Java object types, are pointer equality comparison (the acmp instruction), synchronization (the monitor instructions), all the wait and notify methods of class Object, and non-trivial finalize methods. The clone method is also value-unsafe, although for value types it could be treated as the identity function. Finally, and most importantly, any side effect on an object (however visible) also counts as an value-unsafe operation. A value type may have methods, but such methods must not change the components of the value. It is reasonable and useful to define methods like toString, equals, and hashCode on value types, and also methods which are specifically valuable to users of the value type. Representations of Value Value types have two natural representations in the JVM, unboxed and boxed. An unboxed value consists of the components, as simple variables. For example, the complex number x=(1+2i), in rectangular coordinate form, may be represented in unboxed form by the following pair of variables: /*Complex x = Complex.valueOf(1.0, 2.0):*/ double x_re = 1.0, x_im = 2.0; These variables might be locals, parameters, or fields. Their association as components of a single value is not defined to the JVM. Here is a sample computation which computes the norm of the difference between two complex numbers: double distance(/*Complex x:*/ double x_re, double x_im,         /*Complex y:*/ double y_re, double y_im) {     /*Complex z = x.minus(y):*/     double z_re = x_re - y_re, z_im = x_im - y_im;     /*return z.abs():*/     return Math.sqrt(z_re*z_re + z_im*z_im); } A boxed representation groups component values under a single object reference. The reference is to a ‘wrapper class’ that carries the component values in its fields. (A primitive type can naturally be equated with a trivial value type with just one component of that type. In that view, the wrapper class Integer can serve as a boxed representation of value type int.) The unboxed representation of complex numbers is practical for many uses, but it fails to cover several major use cases: return values, array elements, and generic APIs. The two components of a complex number cannot be directly returned from a Java function, since Java does not support multiple return values. The same story applies to array elements: Java has no ’array of structs’ feature. (Double-length arrays are a possible workaround for complex numbers, but not for value types with heterogeneous components.) By generic APIs I mean both those which use generic types, like Arrays.asList and those which have special case support for primitive types, like String.valueOf and PrintStream.println. Those APIs do not support unboxed values, and offer some problems to boxed values. Any ’real’ JVM type should have a story for returns, arrays, and API interoperability. The basic problem here is that value types fall between primitive types and object types. Value types are clearly more complex than primitive types, and object types are slightly too complicated. Objects are a little bit dangerous to use as value carriers, since object references can be compared for pointer equality, and can be synchronized on. Also, as many Java programmers have observed, there is often a performance cost to using wrapper objects, even on modern JVMs. Even so, wrapper classes are a good starting point for talking about value types. If there were a set of structural rules and restrictions which would prevent value-unsafe operations on value types, wrapper classes would provide a good notation for defining value types. This note attempts to define such rules and restrictions. Let’s Start Coding Now it is time to look at some real code. Here is a definition, written in Java, of a complex number value type. @ValueSafe public final class Complex implements java.io.Serializable {     // immutable component structure:     public final double re, im;     private Complex(double re, double im) {         this.re = re; this.im = im;     }     // interoperability methods:     public String toString() { return "Complex("+re+","+im+")"; }     public List<Double> asList() { return Arrays.asList(re, im); }     public boolean equals(Complex c) {         return re == c.re && im == c.im;     }     public boolean equals(@ValueSafe Object x) {         return x instanceof Complex && equals((Complex) x);     }     public int hashCode() {         return 31*Double.valueOf(re).hashCode()                 + Double.valueOf(im).hashCode();     }     // factory methods:     public static Complex valueOf(double re, double im) {         return new Complex(re, im);     }     public Complex changeRe(double re2) { return valueOf(re2, im); }     public Complex changeIm(double im2) { return valueOf(re, im2); }     public static Complex cast(@ValueSafe Object x) {         return x == null ? ZERO : (Complex) x;     }     // utility methods and constants:     public Complex plus(Complex c)  { return new Complex(re+c.re, im+c.im); }     public Complex minus(Complex c) { return new Complex(re-c.re, im-c.im); }     public double abs() { return Math.sqrt(re*re + im*im); }     public static final Complex PI = valueOf(Math.PI, 0.0);     public static final Complex ZERO = valueOf(0.0, 0.0); } This is not a minimal definition, because it includes some utility methods and other optional parts.  The essential elements are as follows: The class is marked as a value type with an annotation. The class is final, because it does not make sense to create subclasses of value types. The fields of the class are all non-private and final.  (I.e., the type is immutable and structurally transparent.) From the supertype Object, all public non-final methods are overridden. The constructor is private. Beyond these bare essentials, we can observe the following features in this example, which are likely to be typical of all value types: One or more factory methods are responsible for value creation, including a component-wise valueOf method. There are utility methods for complex arithmetic and instance creation, such as plus and changeIm. There are static utility constants, such as PI. The type is serializable, using the default mechanisms. There are methods for converting to and from dynamically typed references, such as asList and cast. The Rules In order to use value types properly, the programmer must avoid value-unsafe operations.  A helpful Java compiler should issue errors (or at least warnings) for code which provably applies value-unsafe operations, and should issue warnings for code which might be correct but does not provably avoid value-unsafe operations.  No such compilers exist today, but to simplify our account here, we will pretend that they do exist. A value-safe type is any class, interface, or type parameter marked with the @ValueSafe annotation, or any subtype of a value-safe type.  If a value-safe class is marked final, it is in fact a value type.  All other value-safe classes must be abstract.  The non-static fields of a value class must be non-public and final, and all its constructors must be private. Under the above rules, a standard interface could be helpful to define value types like Complex.  Here is an example: @ValueSafe public interface ValueType extends java.io.Serializable {     // All methods listed here must get redefined.     // Definitions must be value-safe, which means     // they may depend on component values only.     List<? extends Object> asList();     int hashCode();     boolean equals(@ValueSafe Object c);     String toString(); } //@ValueSafe inherited from supertype: public final class Complex implements ValueType { … The main advantage of such a conventional interface is that (unlike an annotation) it is reified in the runtime type system.  It could appear as an element type or parameter bound, for facilities which are designed to work on value types only.  More broadly, it might assist the JVM to perform dynamic enforcement of the rules for value types. Besides types, the annotation @ValueSafe can mark fields, parameters, local variables, and methods.  (This is redundant when the type is also value-safe, but may be useful when the type is Object or another supertype of a value type.)  Working forward from these annotations, an expression E is defined as value-safe if it satisfies one or more of the following: The type of E is a value-safe type. E names a field, parameter, or local variable whose declaration is marked @ValueSafe. E is a call to a method whose declaration is marked @ValueSafe. E is an assignment to a value-safe variable, field reference, or array reference. E is a cast to a value-safe type from a value-safe expression. E is a conditional expression E0 ? E1 : E2, and both E1 and E2 are value-safe. Assignments to value-safe expressions and initializations of value-safe names must take their values from value-safe expressions. A value-safe expression may not be the subject of a value-unsafe operation.  In particular, it cannot be synchronized on, nor can it be compared with the “==” operator, not even with a null or with another value-safe type. In a program where all of these rules are followed, no value-type value will be subject to a value-unsafe operation.  Thus, the prime axiom of value types will be satisfied, that no two value type will be distinguishable as long as their component values are equal. More Code To illustrate these rules, here are some usage examples for Complex: Complex pi = Complex.valueOf(Math.PI, 0); Complex zero = pi.changeRe(0);  //zero = pi; zero.re = 0; ValueType vtype = pi; @SuppressWarnings("value-unsafe")   Object obj = pi; @ValueSafe Object obj2 = pi; obj2 = new Object();  // ok List<Complex> clist = new ArrayList<Complex>(); clist.add(pi);  // (ok assuming List.add param is @ValueSafe) List<ValueType> vlist = new ArrayList<ValueType>(); vlist.add(pi);  // (ok) List<Object> olist = new ArrayList<Object>(); olist.add(pi);  // warning: "value-unsafe" boolean z = pi.equals(zero); boolean z1 = (pi == zero);  // error: reference comparison on value type boolean z2 = (pi == null);  // error: reference comparison on value type boolean z3 = (pi == obj2);  // error: reference comparison on value type synchronized (pi) { }  // error: synch of value, unpredictable result synchronized (obj2) { }  // unpredictable result Complex qq = pi; qq = null;  // possible NPE; warning: “null-unsafe" qq = (Complex) obj;  // warning: “null-unsafe" qq = Complex.cast(obj);  // OK @SuppressWarnings("null-unsafe")   Complex empty = null;  // possible NPE qq = empty;  // possible NPE (null pollution) The Payoffs It follows from this that either the JVM or the java compiler can replace boxed value-type values with unboxed ones, without affecting normal computations.  Fields and variables of value types can be split into their unboxed components.  Non-static methods on value types can be transformed into static methods which take the components as value parameters. Some common questions arise around this point in any discussion of value types. Why burden the programmer with all these extra rules?  Why not detect programs automagically and perform unboxing transparently?  The answer is that it is easy to break the rules accidently unless they are agreed to by the programmer and enforced.  Automatic unboxing optimizations are tantalizing but (so far) unreachable ideal.  In the current state of the art, it is possible exhibit benchmarks in which automatic unboxing provides the desired effects, but it is not possible to provide a JVM with a performance model that assures the programmer when unboxing will occur.  This is why I’m writing this note, to enlist help from, and provide assurances to, the programmer.  Basically, I’m shooting for a good set of user-supplied “pragmas” to frame the desired optimization. Again, the important thing is that the unboxing must be done reliably, or else programmers will have no reason to work with the extra complexity of the value-safety rules.  There must be a reasonably stable performance model, wherein using a value type has approximately the same performance characteristics as writing the unboxed components as separate Java variables. There are some rough corners to the present scheme.  Since Java fields and array elements are initialized to null, value-type computations which incorporate uninitialized variables can produce null pointer exceptions.  One workaround for this is to require such variables to be null-tested, and the result replaced with a suitable all-zero value of the value type.  That is what the “cast” method does above. Generically typed APIs like List<T> will continue to manipulate boxed values always, at least until we figure out how to do reification of generic type instances.  Use of such APIs will elicit warnings until their type parameters (and/or relevant members) are annotated or typed as value-safe.  Retrofitting List<T> is likely to expose flaws in the present scheme, which we will need to engineer around.  Here are a couple of first approaches: public interface java.util.List<@ValueSafe T> extends Collection<T> { … public interface java.util.List<T extends Object|ValueType> extends Collection<T> { … (The second approach would require disjunctive types, in which value-safety is “contagious” from the constituent types.) With more transformations, the return value types of methods can also be unboxed.  This may require significant bytecode-level transformations, and would work best in the presence of a bytecode representation for multiple value groups, which I have proposed elsewhere under the title “Tuples in the VM”. But for starters, the JVM can apply this transformation under the covers, to internally compiled methods.  This would give a way to express multiple return values and structured return values, which is a significant pain-point for Java programmers, especially those who work with low-level structure types favored by modern vector and graphics processors.  The lack of multiple return values has a strong distorting effect on many Java APIs. Even if the JVM fails to unbox a value, there is still potential benefit to the value type.  Clustered computing systems something have copy operations (serialization or something similar) which apply implicitly to command operands.  When copying JVM objects, it is extremely helpful to know when an object’s identity is important or not.  If an object reference is a copied operand, the system may have to create a proxy handle which points back to the original object, so that side effects are visible.  Proxies must be managed carefully, and this can be expensive.  On the other hand, value types are exactly those types which a JVM can “copy and forget” with no downside. Array types are crucial to bulk data interfaces.  (As data sizes and rates increase, bulk data becomes more important than scalar data, so arrays are definitely accompanying us into the future of computing.)  Value types are very helpful for adding structure to bulk data, so a successful value type mechanism will make it easier for us to express richer forms of bulk data. Unboxing arrays (i.e., arrays containing unboxed values) will provide better cache and memory density, and more direct data movement within clustered or heterogeneous computing systems.  They require the deepest transformations, relative to today’s JVM.  There is an impedance mismatch between value-type arrays and Java’s covariant array typing, so compromises will need to be struck with existing Java semantics.  It is probably worth the effort, since arrays of unboxed value types are inherently more memory-efficient than standard Java arrays, which rely on dependent pointer chains. It may be sufficient to extend the “value-safe” concept to array declarations, and allow low-level transformations to change value-safe array declarations from the standard boxed form into an unboxed tuple-based form.  Such value-safe arrays would not be convertible to Object[] arrays.  Certain connection points, such as Arrays.copyOf and System.arraycopy might need additional input/output combinations, to allow smooth conversion between arrays with boxed and unboxed elements. Alternatively, the correct solution may have to wait until we have enough reification of generic types, and enough operator overloading, to enable an overhaul of Java arrays. Implicit Method Definitions The example of class Complex above may be unattractively complex.  I believe most or all of the elements of the example class are required by the logic of value types. If this is true, a programmer who writes a value type will have to write lots of error-prone boilerplate code.  On the other hand, I think nearly all of the code (except for the domain-specific parts like plus and minus) can be implicitly generated. Java has a rule for implicitly defining a class’s constructor, if no it defines no constructors explicitly.  Likewise, there are rules for providing default access modifiers for interface members.  Because of the highly regular structure of value types, it might be reasonable to perform similar implicit transformations on value types.  Here’s an example of a “highly implicit” definition of a complex number type: public class Complex implements ValueType {  // implicitly final     public double re, im;  // implicitly public final     //implicit methods are defined elementwise from te fields:     //  toString, asList, equals(2), hashCode, valueOf, cast     //optionally, explicit methods (plus, abs, etc.) would go here } In other words, with the right defaults, a simple value type definition can be a one-liner.  The observant reader will have noticed the similarities (and suitable differences) between the explicit methods above and the corresponding methods for List<T>. Another way to abbreviate such a class would be to make an annotation the primary trigger of the functionality, and to add the interface(s) implicitly: public @ValueType class Complex { … // implicitly final, implements ValueType (But to me it seems better to communicate the “magic” via an interface, even if it is rooted in an annotation.) Implicitly Defined Value Types So far we have been working with nominal value types, which is to say that the sequence of typed components is associated with a name and additional methods that convey the intention of the programmer.  A simple ordered pair of floating point numbers can be variously interpreted as (to name a few possibilities) a rectangular or polar complex number or Cartesian point.  The name and the methods convey the intended meaning. But what if we need a truly simple ordered pair of floating point numbers, without any further conceptual baggage?  Perhaps we are writing a method (like “divideAndRemainder”) which naturally returns a pair of numbers instead of a single number.  Wrapping the pair of numbers in a nominal type (like “QuotientAndRemainder”) makes as little sense as wrapping a single return value in a nominal type (like “Quotient”).  What we need here are structural value types commonly known as tuples. For the present discussion, let us assign a conventional, JVM-friendly name to tuples, roughly as follows: public class java.lang.tuple.$DD extends java.lang.tuple.Tuple {      double $1, $2; } Here the component names are fixed and all the required methods are defined implicitly.  The supertype is an abstract class which has suitable shared declarations.  The name itself mentions a JVM-style method parameter descriptor, which may be “cracked” to determine the number and types of the component fields. The odd thing about such a tuple type (and structural types in general) is it must be instantiated lazily, in response to linkage requests from one or more classes that need it.  The JVM and/or its class loaders must be prepared to spin a tuple type on demand, given a simple name reference, $xyz, where the xyz is cracked into a series of component types.  (Specifics of naming and name mangling need some tasteful engineering.) Tuples also seem to demand, even more than nominal types, some support from the language.  (This is probably because notations for non-nominal types work best as combinations of punctuation and type names, rather than named constructors like Function3 or Tuple2.)  At a minimum, languages with tuples usually (I think) have some sort of simple bracket notation for creating tuples, and a corresponding pattern-matching syntax (or “destructuring bind”) for taking tuples apart, at least when they are parameter lists.  Designing such a syntax is no simple thing, because it ought to play well with nominal value types, and also with pre-existing Java features, such as method parameter lists, implicit conversions, generic types, and reflection.  That is a task for another day. Other Use Cases Besides complex numbers and simple tuples there are many use cases for value types.  Many tuple-like types have natural value-type representations. These include rational numbers, point locations and pixel colors, and various kinds of dates and addresses. Other types have a variable-length ‘tail’ of internal values. The most common example of this is String, which is (mathematically) a sequence of UTF-16 character values. Similarly, bit vectors, multiple-precision numbers, and polynomials are composed of sequences of values. Such types include, in their representation, a reference to a variable-sized data structure (often an array) which (somehow) represents the sequence of values. The value type may also include ’header’ information. Variable-sized values often have a length distribution which favors short lengths. In that case, the design of the value type can make the first few values in the sequence be direct ’header’ fields of the value type. In the common case where the header is enough to represent the whole value, the tail can be a shared null value, or even just a null reference. Note that the tail need not be an immutable object, as long as the header type encapsulates it well enough. This is the case with String, where the tail is a mutable (but never mutated) character array. Field types and their order must be a globally visible part of the API.  The structure of the value type must be transparent enough to have a globally consistent unboxed representation, so that all callers and callees agree about the type and order of components  that appear as parameters, return types, and array elements.  This is a trade-off between efficiency and encapsulation, which is forced on us when we remove an indirection enjoyed by boxed representations.  A JVM-only transformation would not care about such visibility, but a bytecode transformation would need to take care that (say) the components of complex numbers would not get swapped after a redefinition of Complex and a partial recompile.  Perhaps constant pool references to value types need to declare the field order as assumed by each API user. This brings up the delicate status of private fields in a value type.  It must always be possible to load, store, and copy value types as coordinated groups, and the JVM performs those movements by moving individual scalar values between locals and stack.  If a component field is not public, what is to prevent hostile code from plucking it out of the tuple using a rogue aload or astore instruction?  Nothing but the verifier, so we may need to give it more smarts, so that it treats value types as inseparable groups of stack slots or locals (something like long or double). My initial thought was to make the fields always public, which would make the security problem moot.  But public is not always the right answer; consider the case of String, where the underlying mutable character array must be encapsulated to prevent security holes.  I believe we can win back both sides of the tradeoff, by training the verifier never to split up the components in an unboxed value.  Just as the verifier encapsulates the two halves of a 64-bit primitive, it can encapsulate the the header and body of an unboxed String, so that no code other than that of class String itself can take apart the values. Similar to String, we could build an efficient multi-precision decimal type along these lines: public final class DecimalValue extends ValueType {     protected final long header;     protected private final BigInteger digits;     public DecimalValue valueOf(int value, int scale) {         assert(scale >= 0);         return new DecimalValue(((long)value << 32) + scale, null);     }     public DecimalValue valueOf(long value, int scale) {         if (value == (int) value)             return valueOf((int)value, scale);         return new DecimalValue(-scale, new BigInteger(value));     } } Values of this type would be passed between methods as two machine words. Small values (those with a significand which fits into 32 bits) would be represented without any heap data at all, unless the DecimalValue itself were boxed. (Note the tension between encapsulation and unboxing in this case.  It would be better if the header and digits fields were private, but depending on where the unboxing information must “leak”, it is probably safer to make a public revelation of the internal structure.) Note that, although an array of Complex can be faked with a double-length array of double, there is no easy way to fake an array of unboxed DecimalValues.  (Either an array of boxed values or a transposed pair of homogeneous arrays would be reasonable fallbacks, in a current JVM.)  Getting the full benefit of unboxing and arrays will require some new JVM magic. Although the JVM emphasizes portability, system dependent code will benefit from using machine-level types larger than 64 bits.  For example, the back end of a linear algebra package might benefit from value types like Float4 which map to stock vector types.  This is probably only worthwhile if the unboxing arrays can be packed with such values. More Daydreams A more finely-divided design for dynamic enforcement of value safety could feature separate marker interfaces for each invariant.  An empty marker interface Unsynchronizable could cause suitable exceptions for monitor instructions on objects in marked classes.  More radically, a Interchangeable marker interface could cause JVM primitives that are sensitive to object identity to raise exceptions; the strangest result would be that the acmp instruction would have to be specified as raising an exception. @ValueSafe public interface ValueType extends java.io.Serializable,         Unsynchronizable, Interchangeable { … public class Complex implements ValueType {     // inherits Serializable, Unsynchronizable, Interchangeable, @ValueSafe     … It seems possible that Integer and the other wrapper types could be retro-fitted as value-safe types.  This is a major change, since wrapper objects would be unsynchronizable and their references interchangeable.  It is likely that code which violates value-safety for wrapper types exists but is uncommon.  It is less plausible to retro-fit String, since the prominent operation String.intern is often used with value-unsafe code. We should also reconsider the distinction between boxed and unboxed values in code.  The design presented above obscures that distinction.  As another thought experiment, we could imagine making a first class distinction in the type system between boxed and unboxed representations.  Since only primitive types are named with a lower-case initial letter, we could define that the capitalized version of a value type name always refers to the boxed representation, while the initial lower-case variant always refers to boxed.  For example: complex pi = complex.valueOf(Math.PI, 0); Complex boxPi = pi;  // convert to boxed myList.add(boxPi); complex z = myList.get(0);  // unbox Such a convention could perhaps absorb the current difference between int and Integer, double and Double. It might also allow the programmer to express a helpful distinction among array types. As said above, array types are crucial to bulk data interfaces, but are limited in the JVM.  Extending arrays beyond the present limitations is worth thinking about; for example, the Maxine JVM implementation has a hybrid object/array type.  Something like this which can also accommodate value type components seems worthwhile.  On the other hand, does it make sense for value types to contain short arrays?  And why should random-access arrays be the end of our design process, when bulk data is often sequentially accessed, and it might make sense to have heterogeneous streams of data as the natural “jumbo” data structure.  These considerations must wait for another day and another note. More Work It seems to me that a good sequence for introducing such value types would be as follows: Add the value-safety restrictions to an experimental version of javac. Code some sample applications with value types, including Complex and DecimalValue. Create an experimental JVM which internally unboxes value types but does not require new bytecodes to do so.  Ensure the feasibility of the performance model for the sample applications. Add tuple-like bytecodes (with or without generic type reification) to a major revision of the JVM, and teach the Java compiler to switch in the new bytecodes without code changes. A staggered roll-out like this would decouple language changes from bytecode changes, which is always a convenient thing. A similar investigation should be applied (concurrently) to array types.  In this case, it seems to me that the starting point is in the JVM: Add an experimental unboxing array data structure to a production JVM, perhaps along the lines of Maxine hybrids.  No bytecode or language support is required at first; everything can be done with encapsulated unsafe operations and/or method handles. Create an experimental JVM which internally unboxes value types but does not require new bytecodes to do so.  Ensure the feasibility of the performance model for the sample applications. Add tuple-like bytecodes (with or without generic type reification) to a major revision of the JVM, and teach the Java compiler to switch in the new bytecodes without code changes. That’s enough musing me for now.  Back to work!

    Read the article

  • How to TDD test that objects are being added to a collection if the collection is private?

    - by Joshua Harris
    Assume that I planned to write a class that worked something like this: public class GameCharacter { private Collection<CharacterEffect> _collection; public void Add(CharacterEffect e) { ... } public void Remove(CharacterEffect e) { ... } public void Contains(CharacterEffect e) { ... } } When added an effect does something to the character and is then added to the _collection. When it is removed the effect reverts the change to the character and is removed from the _collection. It's easy to test if the effect was applied to the character, but how do I test that the effect was added to _collection? What test could I write to start constructing this class. I could write a test where Contains would return true for a certain effect being in _collection, but I can't arrange a case where that function would return true because I haven't implemented the Add method that is needed to place things in _collection. Ok, so since Contains is dependent on having Add working, then why don't I try to create Add first. Well for my first test I need to try and figure out if the effect was added to the _collection. How would I do that? The only way to see if an effect is in _collection is with the Contains function. The only way that I could think to test this would be to use a FakeCollection that Mocks the Add, Remove, and Contains of a real collection, but I don't want _collection being affected by outside sources. I don't want to add a setEffects(Collection effects) function, because I do not want the class to have that functionality. The one thing that I am thinking could work is this: public class GameCharacter<C extends Collection> { private Collection<CharacterEffect> _collection; public GameCharacter() { _collection = new C<CharacterEffect>(); } } But, that is just silly making me declare what some private data structures type is on every declaration of the character. Is there a way for me to test this without breaking TDD principles while still allowing me to keep my collection private?

    Read the article

  • Oracle Partner Tier1, inc. Launches the Tier1 Private Oracle Cloud

    - by Catalin Teodor
    Tier1, Inc. announced the availability of the Tier1 Private Oracle Cloud, the most optimized and protected computing environment for Oracle Applications and databases. Leveraging Oracle's Virtual Compute Appliance (VCA) technology, it’s the only virtual environment certified to use Oracle Trusted Partitions – the Tier1 Private Cloud provides the flexibility to license Oracle software on a virtual CPU basis. Read more!

    Read the article

  • Inheritance of closure objects and overriding of methods

    - by bobikk
    I need to extend a class, which is encapsulated in a closure. This base class is following: var PageController = (function(){ // private static variable var _current_view; return function(request, new_view) { ... // priveleged public function, which has access to the _current_view this.execute = function() { alert("PageController::execute"); } } })(); Inheritance is realised using the following function: function extend(subClass, superClass){ var F = function(){ }; F.prototype = superClass.prototype; subClass.prototype = new F(); subClass.prototype.constructor = subClass; subClass.superclass = superClass.prototype; StartController.cache = ''; if (superClass.prototype.constructor == Object.prototype.constructor) { superClass.prototype.constructor = superClass; } } I subclass the PageController: var StartController = function(request){ // calling the constructor of the super class StartController.superclass.constructor.call(this, request, 'start-view'); } // extending the objects extend(StartController, PageController); // overriding the PageController::execute StartController.prototype.execute = function() { alert('StartController::execute'); } Inheritance is working. I can call every PageController's method from StartController's instance. However, method overriding doesn't work: var startCont = new StartController(); startCont.execute(); alerts "PageController::execute". How should I override this method?

    Read the article

  • Inereritance of clousure objects and overriding of methods

    - by bobikk
    I need to extend a class, which is encapsulated in a closure. This base class is following: var PageController = (function(){ // private static variable var _current_view; return function(request, new_view) { ... // priveleged public function, which has access to the _current_view this.execute = function() { alert("PageController::execute"); } } })();` Inheritance is realised using the following function: function extend(subClass, superClass){ var F = function(){ }; F.prototype = superClass.prototype; subClass.prototype = new F(); subClass.prototype.constructor = subClass; subClass.superclass = superClass.prototype; StartController.cache = ''; if (superClass.prototype.constructor == Object.prototype.constructor) { superClass.prototype.constructor = superClass; } } I subclass the PageController: var StartController = function(request){ // calling the constructor of the super class StartController.superclass.constructor.call(this, request, 'start-view'); } // extending the objects extend(StartController, PageController); // overriding the PageController::execute StartController.prototype.execute = function() { alert('StartController::execute'); } Inheritance is working. I can call every PageController's method from StartController's instance. However, method overriding doesn't work: var startCont = new StartController(); startCont.execute(); alerts "PageController::execute". How should I override this method?

    Read the article

  • Why is one Func valid and the other (almost identical) not.

    - by runrunraygun
    private static Dictionary<Type, Func<string, object>> _parseActions = new Dictionary<Type, Func<string, object>> { { typeof(bool), value => {Convert.ToBoolean(value) ;}} }; The above gives an error Error 14 Not all code paths return a value in lambda expression of type 'System.Func<string,object>' However this below is ok. private static Dictionary<Type, Func<string, object>> _parseActions = new Dictionary<Type, Func<string, object>> { { typeof(bool), value => Convert.ToBoolean(value) } }; I don't understand the difference between the two. I thought the extra braces in example1 are to allow us to use multiple lines in the anon function so why have they affected the meaning of the code?

    Read the article

  • What to name 2 methods with same signatures

    - by coffeeaddict
    Initially I had a method in our DL that would take in the object it's updating like so: internal void UpdateCash(Cash Cash) { using (OurCustomDbConnection conn = CreateConnection("UpdateCash")) { conn.CommandText = @"update Cash set captureID = @captureID, ac_code = @acCode, captureDate = @captureDate, errmsg = @errorMessage, isDebit = @isDebit, SourceInfoID = @sourceInfoID, PayPalTransactionInfoID = @payPalTransactionInfoID, CreditCardTransactionInfoID = @CreditCardTransactionInfoID where id = @cashID"; conn.AddParam("@captureID", cash.CaptureID); conn.AddParam("@acCode", cash.ActionCode); conn.AddParam("@captureDate", cash.CaptureDate); conn.AddParam("@errorMessage", cash.ErrorMessage); conn.AddParam("@isDebit", cyberCash.IsDebit); conn.AddParam("@PayPalTransactionInfoID", cash.PayPalTransactionInfoID); conn.AddParam("@CreditCardTransactionInfoID", cash.CreditCardTransactionInfoID); conn.AddParam("@sourceInfoID", cash.SourceInfoID); conn.AddParam("@cashID", cash.Id); conn.ExecuteNonQuery(); } } My boss felt that creating an object every time just to update one or two fields is overkill. But I had a couple places in code using this. He recommended using just UpdateCash and sending in the ID for CAsh and field I want to update. Well the problem is I have 2 places in code using my original method. And those 2 places are updating 2 completely different fields in the Cash table. Before I was just able to get the existing Cash record and shove it into a Cash object, then update the properties I wanted to be updated in the DB, then send back the cash object to my method above. I need some advice on what to do here. I have 2 methods and they have the same signature. I'm not quite sure what to rename these because both are updating 2 completely different fields in the Cash table: internal void UpdateCash(int cashID, int paypalCaptureID) { using (OurCustomDbConnection conn = CreateConnection("UpdateCash")) { conn.CommandText = @"update Cash set CaptureID = @paypalCaptureID where id = @cashID"; conn.AddParam("@captureID", paypalCaptureID); conn.ExecuteNonQuery(); } } internal void UpdateCash(int cashID, int PayPalTransactionInfoID) { using (OurCustomDbConnection conn = CreateConnection("UpdateCash")) { conn.CommandText = @"update Cash set PaymentSourceID = @PayPalTransactionInfoID where id = @cashID"; conn.AddParam("@PayPalTransactionInfoID", PayPalTransactionInfoID); conn.ExecuteNonQuery(); } } So I thought hmm, maybe change the names to these so that they are now unique and somewhat explain what field its updating: UpdateCashOrderID UpdateCashTransactionInfoID ok but that's not really very good names. And I can't go too generic, for example: UpdateCashTransaction(int cashID, paypalTransactionID) What if we have different types of transactionIDs that the cash record holds besides just the paypalTransactionInfoID? such as the creditCardInfoID? Then what? Transaction doesn't tell me what kind. And furthermore what if you're updating 2 fields so you have 2 params next to the cashID param: UpdateCashTransaction(int cashID, paypalTransactionID, someOtherFieldIWantToUpdate) see my frustration? what's the best way to handle this is my boss doesn't like my first route?

    Read the article

  • Does importing of packages change visibility of classes?

    - by Roman
    I jsut learned that A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package. This is a clear statement. But this information interfere with my understanding of importing of packages (which easily can be wrong). I thought that importing a package I make classes from the imported package visible to the importing class. So, how does it work? Are public classes visible to all classes everywhere under condition that the package containing the public class is imported? Or there is not such a condition? What about the package-private classes? They are invisible no mater if the containing package was imported or not? ADDED: It seems to me that I got 2 answers which are marked as good (up-voted) and which contradict eachother.

    Read the article

  • Mocking methods that call other methods Still hit database.Can I avoid it?

    - by devnet247
    Hi, It has been decided to write some unit tests using moq etc..It's lots of legacy code c# (this is beyond my control so cannot answer the whys of this) Now how do you cope with a scenario when you dont want to hit the database but you indirectly still hit the database? This is something I put together it's not the real code but gives you an idea. How would you deal with this sort of scenario? Basically calling a method on a mocked interface still makes a dal call as inside that method there are other methods not part of that interface?Hope it's clear [TestFixture] public class Can_Test_this_legacy_code { [Test] public void Should_be_able_to_mock_login() { var mock = new Mock<ILoginDal>(); User user; var userName = "Jo"; var password = "password"; mock.Setup(x => x.login(It.IsAny<string>(), It.IsAny<string>(),out user)); var bizLogin = new BizLogin(mock.Object); bizLogin.Login(userName, password, out user); } } public class BizLogin { private readonly ILoginDal _login; public BizLogin(ILoginDal login) { _login = login; } public void Login(string userName, string password, out User user) { //Even if I dont want to this will call the DAL!!!!! var bizPermission = new BizPermission(); var permissionList = bizPermission.GetPermissions(userName); //Method I am actually testing _login.login(userName,password,out user); } } public class BizPermission { public List<Permission>GetPermissions(string userName) { var dal=new PermissionDal(); var permissionlist= dal.GetPermissions(userName); return permissionlist; } } public class PermissionDal { public List<Permission> GetPermissions(string userName) { //I SHOULD NOT BE GETTING HERE!!!!!! return new List<Permission>(); } } public interface ILoginDal { void login(string userName, string password,out User user); } public interface IOtherStuffDal { List<Permission> GetPermissions(); } public class Permission { public int Id { get; set; } public string Name { get; set; } } Any suggestions? Am I missing the obvious? Is this Untestable code? Very very grateful for any suggestions.

    Read the article

  • Efficient file buffering & scanning methods for large files in python

    - by eblume
    The description of the problem I am having is a bit complicated, and I will err on the side of providing more complete information. For the impatient, here is the briefest way I can summarize it: What is the fastest (least execution time) way to split a text file in to ALL (overlapping) substrings of size N (bound N, eg 36) while throwing out newline characters. I am writing a module which parses files in the FASTA ascii-based genome format. These files comprise what is known as the 'hg18' human reference genome, which you can download from the UCSC genome browser (go slugs!) if you like. As you will notice, the genome files are composed of chr[1..22].fa and chr[XY].fa, as well as a set of other small files which are not used in this module. Several modules already exist for parsing FASTA files, such as BioPython's SeqIO. (Sorry, I'd post a link, but I don't have the points to do so yet.) Unfortunately, every module I've been able to find doesn't do the specific operation I am trying to do. My module needs to split the genome data ('CAGTACGTCAGACTATACGGAGCTA' could be a line, for instance) in to every single overlapping N-length substring. Let me give an example using a very small file (the actual chromosome files are between 355 and 20 million characters long) and N=8 import cStringIO example_file = cStringIO.StringIO("""\ header CAGTcag TFgcACF """) for read in parse(example_file): ... print read ... CAGTCAGTF AGTCAGTFG GTCAGTFGC TCAGTFGCA CAGTFGCAC AGTFGCACF The function that I found had the absolute best performance from the methods I could think of is this: def parse(file): size = 8 # of course in my code this is a function argument file.readline() # skip past the header buffer = '' for line in file: buffer += line.rstrip().upper() while len(buffer) = size: yield buffer[:size] buffer = buffer[1:] This works, but unfortunately it still takes about 1.5 hours (see note below) to parse the human genome this way. Perhaps this is the very best I am going to see with this method (a complete code refactor might be in order, but I'd like to avoid it as this approach has some very specific advantages in other areas of the code), but I thought I would turn this over to the community. Thanks! Note, this time includes a lot of extra calculation, such as computing the opposing strand read and doing hashtable lookups on a hash of approximately 5G in size. Post-answer conclusion: It turns out that using fileobj.read() and then manipulating the resulting string (string.replace(), etc.) took relatively little time and memory compared to the remainder of the program, and so I used that approach. Thanks everyone!

    Read the article

  • Override java methods without affecting parent behaviour

    - by Timmmm
    suppose I have this classes (sorry it's kind of hard to think of a simple example here; I don't want any "why would you want to do that?" answers!): class Squarer { public void setValue(int v) { mV = v; } public int getValue() { return mV; } private int mV; public void square() { setValue(getValue() * getValue()); } } class OnlyOddInputsSquarer extends Squarer { @Override public void setValue(int v) { if (v % 2 == 0) { print("Sorry, this class only lets you square odd numbers!") return; } super.setValue(v); } } auto s = new OnlyOddInputsSquarer(); s.setValue(3); s.square(); This won't work. When Squarer.square() calls setValue(), it will go to OnlyOddInputsSquarer.setValue() which will reject all its values (since all squares are even). Is there any way I can override setValue() so that all the functions in Squarer still use the method defined there? PS: Sorry, java doesn't have an auto keyword you haven't heard about! Wishful thinking on my part.

    Read the article

  • Does importing of packages change visibility of classes?

    - by Roman
    I jsut learned that A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package. This is a clear statement. But this information interfere with my understanding of importing of packages (which easily can be wrong). I thought that importing a package I make classes from the imported package visible to the importing class. So, how does it work? Are public classes visible to all classes everywhere under condition that the package containing the public class is imported? Or there is not such a condition? What about the package-private classes? They are invisible no mater if the containing package was imported or not? ADDED: It seems to me that I got 2 answers which are marked as good (up-voted) and which contradict eachother.

    Read the article

  • FRIEND_TEST in Google Test - possible circular dependency?

    - by Mihaela
    I am trying to figure out how FRIEND_TEST works in Google Tests. http://code.google.com/p/googletest/wiki/AdvancedGuide#Private_Class_Members I am looking at the following item, trying to implement it in my code: // foo.h #include "gtest/gtest_prod.h" // Defines FRIEND_TEST. class Foo { ... private: FRIEND_TEST(FooTest, BarReturnsZeroOnNull); int Bar(void* x); }; // foo_test.cc ... TEST(FooTest, BarReturnsZeroOnNull) { Foo foo; EXPECT_EQ(0, foo.Bar(NULL)); // Uses Foo's private member Bar(). } In the code above, the piece that I can't see, is that foo_test.cc must include foo.h, in order to have access to Foo and Bar(). [Perhaps it works differently for Google ? in my code, I must include it] That will result in circular dependency... Am I missing something ?

    Read the article

  • Trouble with abstract generic methods

    - by DanM
    Let's say I have a class library that defines a couple entity interfaces: public interface ISomeEntity { /* ... */ } public interface ISomeOtherEntity { /* ... */ } This library also defines an IRepository interface: public interface IRepository<TEntity> { /* ... */ } And finally, the library has an abstract class called RepositorySourceBase (see below), which the main project needs to implement. The goal of this class is to allow the base class to grab new Repository objects at runtime. Because certain repositories are needed (in this example a repository for ISomeEntity and ISomeOtherEntity), I'm trying to write generic overloads of the GetNew<TEntity>() method. The following implementation doesn't compile (the second GetNew() method gets flagged as "already defined" even though the where clause is different), but it gets at what I'm trying to accomplish: public abstract class RepositorySourceBase // This doesn't work! { public abstract Repository<TEntity> GetNew<TEntity>() where TEntity : SomeEntity; public abstract Repository<TEntity> GetNew<TEntity>() where TEntity : SomeOtherEntity; } The intended usage of this class would be something like this: public class RepositorySourceTester { public RepositorySourceTester(RepositorySourceBase repositorySource) { var someRepository = repositorySource.GetNew<ISomeEntity>(); var someOtherRepository = repositorySource.GetNew<ISomeOtherEntity>(); } } Meanwhile, over in my main project (which references the library project), I have implementations of ISomeEntity and ISomeOtherEntity: public class SomeEntity : ISomeEntity { /* ... */ } public class SomeOtherEntity : ISomeOtherEntity { /* ... */ } The main project also has an implementation for IRepository<TEntity>: public class Repository<TEntity> : IRepository<TEntity> { public Repository(string message) { } } And most importantly, it has an implementation of the abstract RepositorySourceBase: public class RepositorySource : RepositorySourceBase { public override Repository<SomeEntity> GetNew() { return new Repository<SomeEntity>("stuff only I know"); } public override Repository<SomeOtherEntity> GetNew() { return new Repository<SomeOtherEntity>("other stuff only I know"); } } Just as with RepositorySourceBase, the second GetNew() method gets flagged as "already defined". So, C# basically think I'm repeating the same method because there's no way to distinguish the methods from parameters, but if you look at my usage example, it seems like I should be able to distinguish which GetNew() I want from the generic type parameter, e.g, <ISomeEntity> or <ISomeOtherEntity>. What do I need to do to get this to work?

    Read the article

  • Strange behavior when overloading methods in Java

    - by Sep
    I came across this weird (in my opinion) behavior today. Take this simple Test class: public class Test { public static void main(String[] args) { Test t = new Test(); t.run(); } private void run() { List<Object> list = new ArrayList<Object>(); list.add(new Object()); list.add(new Object()); method(list); } public void method(Object o) { System.out.println("Object"); } public void method(List<Object> o) { System.out.println("List of Objects"); } } It behaves the way you expect, printing "List of Objects". But if you change the following three lines: List<String> list = new ArrayList<String>(); list.add(""); list.add(""); you will get "Object" instead. I tried this a few other ways and got the same result. Is this a bug or is it a normal behavior? And if it is normal, can someone explain why? Thanks.

    Read the article

  • Raising C# events with an extension method - is it bad?

    - by Kyralessa
    We're all familiar with the horror that is C# event declaration. To ensure thread-safety, the standard is to write something like this: public event EventHandler SomethingHappened; protected virtual void OnSomethingHappened(EventArgs e) { var handler = SomethingHappened; if (handler != null) handler(this, e); } Recently in some other question on this board (which I can't find now), someone pointed out that extension methods could be used nicely in this scenario. Here's one way to do it: static public class EventExtensions { static public void RaiseEvent(this EventHandler @event, object sender, EventArgs e) { var handler = @event; if (handler != null) handler(sender, e); } static public void RaiseEvent<T>(this EventHandler<T> @event, object sender, T e) where T : EventArgs { var handler = @event; if (handler != null) handler(sender, e); } } With these extension methods in place, all you need to declare and raise an event is something like this: public event EventHandler SomethingHappened; void SomeMethod() { this.SomethingHappened.RaiseEvent(this, EventArgs.Empty); } My question: Is this a good idea? Are we missing anything by not having the standard On method? (One thing I notice is that it doesn't work with events that have explicit add/remove code.)

    Read the article

  • Most awkward/misleading method in Java Base API ?

    - by JG
    I was recently trying to convert a string literal into a boolean, when the method "boolean Boolean.getBoolean(String name)" popped out of the auto-complete window. There was also another method ("boolean Boolean.parseBoolean(String s)") appearing right after, which lead me to search to find out what were the differences between these two, as they both seemed to do the same. It turns out that what Boolean.getBoolean(String name) really does is to check if there exists a System property (!) of the given name and if its value is true. I think this is very misleading, as I'm definitely not expecting that a method of Boolean is actually making a call to System.getProperty, and just by looking at the method signature, it sure looks (at least to me) like it should be used to parse a String as a boolean. Sure, the javadoc states it clearly, but I still think the method has a misleading name and is not in the right place. Other primitive type wrappers, such as Integer also have a similar method. Also, it doesn't seem to be a very useful method to belong in the base API, as I think it's not very common to have something like -Darg=true. Maybe it's a good question for a Java position interview: "What is the output of Boolean.getBoolean("true")?". I believe a more appropriate place for those methods would be in the System class, e.g., getPropertyAsBoolean; but again, I still think it's unnecessary to have these methods in the base API. It'd make sense to have these in something like the Properties class, where it's very common to do this kind of type conversions. What do you think of all this ? Also, if there's another "awkward" method that you're aware of, please post it. N.B. I know I can use Boolean.valueOf or Boolean.parseBoolean to convert a string literal into a boolean, but I'm just looking to discuss the API design.

    Read the article

  • C#: An object reference is required for the non-static field, method, or Property

    - by Omin
    I feel bad for asking this when there are so many questions that are related but I was not able to find/understand the answer I am looking for. // 2. Develop a program to convert currency X to currency Y and visa versa. using System; class Problem2 { static void Main (string[] args) { while (true) { Console.WriteLine ("1. Currency Conversion from CAD to Won"); Console.WriteLine ("2. Currency Conversion from Won to Cad"); Console.Write ("Choose from the Following: (1 or 2)? "); int option = int.Parse( Console.ReadLine() ); //double x; if (option == 1) { Console.WriteLine ("Type in the amount you would like to Convert CAD to Won: "); //double y =double.Parse( Console.ReadLine()); //Console.WriteLine( cadToWon( y ) ); Console.WriteLine( cadToWon( double.Parse( Console.ReadLine() ) )); } if (option == 2) { Console.WriteLine ("Type in the amount you would like to Convert Won to CAD: "); Console.WriteLine( wonToCad (double.Parse( Console.ReadLine()))); } } } double cadToWon( double x ) { return x * 1113.26; } double wonToCad( double x) { return x / 1113.26; } } This give me the Error messgae "An object reference is required for the non-static field, method, or property 'Problem2..." I know that I'll be able to run the program if I add static infront of the methods but I'm wondering why I need it (I think it's because Main is static?) and what do I need to change in order to use these methods without adding static to them? Thank you

    Read the article

  • C# Method not returning a unique value when it should be.

    - by Josh King
    I have two methods, generateNounPhrase() and generateVerbPhrase(). VerbPhrase will call on NounPhrase half the time and it's output the output should be something to the effect of: the empty lot re-animates this pyramid (bold indicating where generateNounPhrase() is logically called). The true output however is in the form of: the empty lot re-animates the empty lot At first I thought my randomIndex method wasn't working as I had intended, but if I run the two methods again I do get different noun phrases but they are not unique at the beginning and end of the sentence as they should be. Any idea what I am doing wrong in order to get one method to show the same result? private string generateNounPhrase() { string nounPhraseString = ""; nounPhraseString = nounMarkersStringList[randomIndex(0,nounMarkersStringList.Count-1)]; if (included(1, 4, 2) == true) { nounPhraseString += " " + adjectivesStringList[randomIndex(0, adjectivesStringList.Count - 1)]; } nounPhraseString += " " + nounsStringList[randomIndex(0, nounsStringList.Count - 1)]; return nounPhraseString; } private string generateVerbPhrase() { string verbPhraseString = ""; if (included(1, 4, 2) == true) { verbPhraseString = intransitiveVerbsStringList[randomIndex(0, intransitiveVerbsStringList.Count - 1)]; } else { verbPhraseString = transitiveVerbsStringList[randomIndex(0, transitiveVerbsStringList.Count - 1)] + " " + generateNounPhrase(); } return verbPhraseString; }

    Read the article

  • Finding an odd perfect number

    - by Coin Bird
    I wrote these two methods to determine if a number is perfect. My prof wants me to combine them to find out if there is an odd perfect number. I know there isn't one(that is known), but I need to actually write the code to prove that. The issue is with my main method. I tested the two test methods. I tried debugging and it gets stuck on the number 5, though I can't figure out why. Here is my code: public class Lab6 { public static void main (String[]args) { int testNum = 3; while (testNum != sum_of_divisors(testNum) && testNum%2 != 0) testNum++; } public static int sum_of_divisors(int numDiv) { int count = 1; int totalDivisors = 0; while (count < numDiv) if (numDiv%count == 0) { totalDivisors = totalDivisors + count; count++; } else count++; return totalDivisors; } public static boolean is_perfect(int numPerfect) { int count = 1; int totalPerfect = 0; while (totalPerfect < numPerfect) { totalPerfect = totalPerfect + count; count++; } if (numPerfect == totalPerfect) return true; else return false; } }

    Read the article

< Previous Page | 48 49 50 51 52 53 54 55 56 57 58 59  | Next Page >