I'm new to ADF BC and I'm trying to add an accessorIterator to my bindings.
However, I'm getting the following error message:
I'd like to know what's the difference between Accessor Iterator, Method Iterator and Iterator. I've been reading lots of documentation on ADF BC and I can't seem to find any explanation on the different iterators.
Thanks
It kinda self-explanatory.
Quoting documentation:
Iterator: Iterates over the data items of a collection.
Method iterator: Iterates the results returned from a method. A method
iterator is always related to a method action binding, which creates
the binding to the actual method to be invoked. The method action
binding is what encapsulates the details about how to invoke the
method and what parameters (if any) the method is expecting. The
method iterator binding handles iterating over the return from that
method.
Accessor iterator: Iterates over detail collections returned by
accessor methods. Accessor iterators are always related to a master
iterator, which is a method iterator. The accessor iterator returns
the detail objects related to the current object in the master (or
method) iterator
In most cases you need Iterator to work with your bc's data.
accessorIterator : Access the accessor of ViewObjects.
iterator : Access the ViewObject.
methodIterator : Access the custom methods of viewObject.
Related
I need to get and set a property of another class from a method and therefore need to pass in either the property reference of lambdas for the getter and the setter:
Passing in the property reference
otherInstance::property
Passing in a lambda for the getter and one for the setter:
{otherInstance.property} // getter
{value -> otherInstance.property = value} // setter
I like the first one, because for me the code is easier to read and shorter, but my alarm bells ring when I read about it on the official documentation, because of the term "reflection". My knowledge from Java is that reflection generally isn't a good thing. Is that also valid with Kotlin? Is it valid with this case? Is one of both ways (property reference or lambdas) more performant or more safe?
By using KMutableProperty0 you would technically be exposing an object that can be used for reflection. If you want to be strict about avoiding reflection, you could use the separate function references for the getter and setter. Note that it's not necessary to pass a lambda as a function reference to a higher-order function. The compiler can interpret property references as functions if the effective signature matches. This would unfortunately mean having to pass the property reference twice. Unfortunately, the setter has to be retrieved via what is technically reflection in this case:
class Test (var x: Int)
fun foo(getter: () -> Int, setter: (Int) -> Unit) {
//...
}
val test = Test(1)
foo(test::x, test::x.setter)
// Zero reflection call:
foo(test::x) { test.x = it }
At some point you have to question how badly you want to avoid reflection, because the above code looks very messy to me. If your class takes a KMutableProperty0 reference, it is much simpler to use. As long as your receiving function isn't using the reference to introspect the code, and only calls get() or set() on it, you are not really using reflection in the ways that are suggested should be avoided.
fun foo(property: KMutableProperty0<Int>) {
//...
}
val test = Test(1)
foo(test::x)
The documentation is about Member references and reflection,
If you are referring to Property references which isn't using reflection itself,
Reflection is only referred in different section Obtaining member references from a class reference
dynamically inspect an object to see e.g. what properties and functions it contains and which annotations exist on them. This is called reflection, and it's not very performant, so avoid it unless you really need it.
Kotlin has got its own reflection library (kotlin-reflect.jar must be included in your build). When targeting the JVM, you can also use the Java reflection facilities. Note that the Kotlin reflection isn't quite feature-complete yet - in particular, you can't use it to inspect built-in classes like String.
I'm trying to achieve this behavior with Mockito:
When object of type O is applied to a method M, the mock should execute another method on the object of type O passing itself as a parameter.
Is it possible after all?
You can probably use some combination of doAnswer and the when combined with Mockito.any. doAnswer is a part of PowerMockito, which helps extend a lot of the mocking you may want to do.
NOTE, doAnswer is used as an example for void functions. For a non-void you can use your standard Mockito.when(MOCK.call).then(RESULT)
PowerMockito.doAnswer(new org.mockito.stubbing.Answer<Object>() {
#Override
public Object answer(InvocationOnMock invocation) throws Throwable {
//Do whatever to Object O here.
return null;
}).when(MOCKOBJECT.methodCall(Mockito.any(O.class)));
This then does the helpful doAnswer functionality on a mock object, and using the when you can assign it to catch for any specific class of object (instead of having to specify an exact object it should be expecting). Using the Mockito.any(Class.class)) as part of the parameters lets Mockito know to fire off your doWhatever, when it hits a method call with ANY object of the specified type passed in.
RealBasic's Introspection is kinda of different than what I expected.
My intention is:
Create a MainObject from which other objects will inherit two, three methods, to simplify.
Method 1-> Returns to the child class itself all of its properties, types and values.
Method 2-> Would call Method1 and with the information, save the child Object.
So, for method 1 I thought about writing a generalised introspection which for each child class would easily return what I need for Method 2 to do its work.
Why do I want this? So I can have tens of objects knowing how to save, draw themselves without worrying too much about a modification here or there on the properties etc...
But using what RealBasic tutorials and reference offers doesn't work, since it requires me to have it happening outside the object etc... i.e.: I can easily, inside ObjectA, get ObjectB's properties, methods etc, but I want to get inside ObjectA, A's properties, not B's
Thanks in advance...
I've found out how... Very simple, create the MainClass and inside of it a simple method WhoAmI which could return an array, dictionary etc...
Dim thisClassTypeInfo As Introspection.TypeInfo = Introspection.GetType(Self)
Dim thisClassProperties() As Introspection.PropertyInfo = thisClassTypeInfo.GetProperties
Dim thisClassMethods() As Introspection.MethodInfo = thisClassTypeInfo.GetMethods
For Each myProperty As Introspection.PropertyInfo In thisClassProperties
// Then here use myProperty.Name, myProperty.Value(Self).StringValue
// or myProperty.Value(Self).anyotheroption and create a dictionary
// or array with the results and return it.
Next
class A
constructor: ->
method: ->
In the above example, method is not bound to the class and neither is constructor.
class B
constructor: ->
method: =>
In this case, method is bound to the class. It behaves as you expect a normal object method to behave and has access to all of class B's fields. But the constructor is not bound? That seems strange. So i tried the following.
class C
constructor: =>
method: =>
This doesn't compile. I would expect the syntax to be the same on all methods that are bound to a class.
I would like to regard the -> operator as a static operator and the => operator as a dynamic operator. But it doesn't seem like you can. If you could, a method with the -> operator could not be called with super. But, in actuality, you can. Why does this make sense for the syntax of an object oriented language? This seems to not agree with most object oriented languages inheritance rules.
Try looking at how the code compiles. When you use =>, the methods are bound inside the constructor. Thus, it doesn't make any sense to use => for a constructor - when would it be bound?
I'm not sure about your issue with static vs. dynamic operators, but you can definitely call methods defined with the -> operator with super. The only thing -> vs => affects is that the => ensures that this is the object in question regardless of how it is called.
Summary of comments:
Calling the difference between -> and => analogous to static vs. dynamic (or virtual) does not quite convey what those operators do. They are used to get different behavior from javascript's this variable. For example, look at the following code:
class C
constructor: ->
method1: ->
console.log this
method2: =>
console.log this
c = new C()
c.method1() //prints c
f = c.method1;f() //prints window
c.method2() //prints c
f = c.method2;f() //prints c
The difference is in the second way we call each method: if the method is not "bound" to the object, its this is set by looking at what precedes the method call (separated by a .). In the first case, this is c, but in the second f isn't being called on an object, so this is set to window. method2 doesn't have this problem because it is bound to the object.
Normally, you can think of the the constructor function automatically being bound to the object that it is constructing (thus, you can't bind it with =>). However, its worth noting that this isn't quite what's happening, because if a constructor returns an object, that will be the return value of the construction, rather than the this during the constructor.
I think you're massively confused as to the meaning of the '=>', or fat arrow.
First off though, your examples aren't actually valid coffeescript, are they? There is no -> after the class declaration. Adding one is a compiler error.
Back to the fat arrow, there's no mapping to the terms static and dynamic that I can think of, that would apply here. Instead the fat arrow is a convenient syntactic sugar for wrapping a function with a closure that contains the reference to the object you're calling the function on.
The C++ analog is to possibly to say that the fat arrow is a method for automatically creating a functor: it lets you give the function as a callback to a third party who can call it without knowing your object, but where the code invoked inside will have access to your object as the this pointer. It serves no other purpose, and has no bearing on whether a function can be overloaded, or whether it can have access to super.
Yeah, I'm struggling with that. I cannot distinguish among them because every explanation I read is so unclear and philosophical enough. Can someone clear up these definitions for me ? Thanks guys.
These definitions apply as much to procedural-programming as oop ? Thanks.
Over time, the way people use each of these terms has changed (and will likely keep changing), but here's what they probably mean if you're reading articles written in the last decade or so:
Functions (aka subroutines) are relatively self-contained, relatively independent pieces of code that make up a larger program.
Methods are functions attached to specific classes (or instances) in object-oriented programming.
Properties are an object-oriented idiom. The term describes a one or two functions (depending on the desired program behavior) - a 'getter' that retrieves a value and a 'setter' that sets a value. By convention, properties usually don't have many side-effects. (And the side-effects they do have usually have limited scope: they may validate the item being set, notify listeners of a change, or convert an object's private data to or from a publicly-declared type.)
Function is a combination of instructions coupled together to achieve some result. It may take arguments and return result. If a function doesn't return a result it is usually called a procedure. Examples:
function drawLine(x1, y1, x2, y2):
// draws a line using Bresenham's algorithm from x1,y1 to x2,y2.
// doesn't return anything
function <number> add(a, b):
// adds a to b and returns the result as a number
return a + b
So functions are to do some particular work. For example, when you need to draw a polygon of 3 lines as a part of a vector image it is more convenient to call drawLine thrice than to put all the routine for line drawing inline.
Methods ("member functions") are similar to functions, they belongs to classes or objects and usually expresses the verbs of the objects/class. For example, an object of type Window usually would have methods open and close which do corresponding operations to the object they belong.
Properties are as in everyday language and technically are fields of objects/classes with dedicated getter/setter routines (which can be considered as methods. There are languages that don't have properties and this behavior is achieved using a private field+get/set methods.).
Field - A field is a variable of any type that is declared directly in a class or struct. Fields are members of their containing type.
Property - A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field.
Method - A method is a code block containing a series of statements. In C#, every executed instruction is done so in the context of a method.
Procedure - A procedure is a code block containing a series of statements.
Function - A function is a code block containing a series of statements. That return operation result.
Function is a standalone construction like trim(), strlen(), fopen() etc.
function myAbcFunction() { ... }
Method is a function of object. It is defined in class. Property is just property of object:
class MyClass {
public $property; // Public property: $objInstance->property
protected $property2; // Protected property
public function doSth() {
// That's a method. $objInstance->doSth();
}
}
I suggest read the manual Classes and Objects chapter.
In OOP the primary structure is an object.
Method is a named action which can be applied to the object.
Property is a named value, which the object has. For example, object Human has the property 'Age'.
function is a more general thing, than a method. It is just an action, that doesn't belong to any object. But method is a function that belongs to the object.
a)Function
Refers to block of statements that perform a particular task and return a value.
b)Procedure
Refers to the building blocks of a program that do not return a value when called.
c)Method
Refers to the action that object can perform.