Is it safe to say that if for some type a copy function is an identity function, then the type is immutable?
Related
I need to know if there is any way to define a new type in Julia that acts like primitive data type, for example:
struct test
att1::MyType
end
Let's suppose that my MyType is only from 1 to 10. So if I make an instance like this:
test1=test(11) it should give me an error.
I can guess there is an easier way to do this, but I need to extend MyType more than just from 1 to 10.
The way to define primitive types is described here in the Julia Manual.
In the InlineStrings.jl package you have an excellent demo code here how you can define such types in practice with custom constructors (which I assume you want as I guess you want to perform checking for valid range of arguments when you run the constructor of your type).
Using reflection, we can get the type name, storage size and the function of the given type(such as uint64, user-defined struct and so on). Even, we can modify some fields of the given type.
How does golang implement reflections? I guess the following ways:
Every type in golang, including user-defined type, itself has the information about type name, fields name and the function name. Golang reflection just reads these information or call the function.
Through some mechanism, Golang can get the type name, storage size and so on. And the type itself doesn’t have these information.
I have read the golang reflection code roughly. I guessed that golang used the second way.
Who can describe the concrete implement of reflection? Or recommend me some documents? Reading all code is difficult for me.
This is just an overview and it might be not 100% accurate but hopefully you will find it helpful.
At build time Go linker will embed information about all types used by the application into the executable (https://github.com/golang/go/blob/master/src/runtime/symtab.go#L39)
Each interface value contains a pointer to the data type descriptor (https://github.com/golang/go/blob/master/src/runtime/type.go#L14)
During conversion from a type that is known at compile time to an interface value Go compiler will point type descriptor of this interface value to the concrete type descriptor (it is known at compile time!).
E.g. when you call reflect.TypeOf(uint(87)):
an interface value is created by the compiler that references uint type descriptor
this interface value is passed to reflect.TypeOf function as argument
reflect.TypeOf function uses type descriptor that has been stored by the linker in the executable to get the align (and other) information about uint type.
The description of interfaces is well described here: The Laws of Reflection.
A variable of interface type stores a pair: the concrete value
assigned to the variable, and that value's type descriptor.
Basically, type are known statically from your code. More flexible interface types keep the original underlying type for getting back to the original data type.
If an object is created inside a function and the function returns that type of oject how is the memory handled.
Example:
Public Function GetEmployee(employeeid as integer) as employee
Dim oEmployee as new employee
oEmployee.FirstName="Bob"
...
...
return oEmployee
end function
Does the variable that receive the object still a pointer to the memory location that was used inside the function?
What about when you do a oEmployee2=oEmployee
Is oEmployee2 just a pointer? And any changes to oEmployee will now affect the other. Just trying to understand it from a memory perspective and how that scope works
Thanks
Assuming employee is a reference type (e.g. any class) the method will return a reference (similar in concept to a pointer in unmanaged languages) to the object instance (usually on the heap). Since only one object instance exists, all changes to it will affect the instance.
If employee is a value type (e.g any struct or primitive type) a separate copy of the instance is returned.
Assuming oEmployee is a reference type (not a struct), if you pass it as an argument, then you are passing the reference. In .NET you should think in terms of Reference types vs Value types.
This article really helped me understand how memory is allocated when I was starting out.
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx
Is there any way to 'dynamically'/reflectively/etc create a new instance of a class with arguments in Scala?
For example, something like:
class C(x: String)
manifest[C].erasure.newInstance("string")
But that compiles. (This is also, rest assured, being used in a context that makes much more sense than this simplified example!)
erasure is of type java.lang.Class, so you can use constructors (anyway you don't need manifest in this simple case - you can just use classOf[C]). Instead of calling newinstance directly, you can at first find correspondent constructor with getConstructor method (with correspondent argument types), and then just call newInstance on it:
classOf[C].getConstructor(classOf[String]).newInstance("string")
I would like to create a macro that takes a string as a parameter and evaluates that to an object. Something like:
#macro( valueTest $objRef)
#define( $obj )#evaluate("$${objRef}")#end
$obj.foo ## This would have to be translated to $obj.getFoo()
#end
Unfortunately the $obj variable does not point to object reference that could be used to call methods. $obj is a String and $obj.foo does not try to execute getFoo.
Somewhy I have a feeling that this is the nature of evaluate and it is not possible to do what I want to.
the reason why I want to do smth like this is because we have quite few macros that take both command bind path and command itself as a parameter and I am hoping the latter could be derived from first.
Unfortunately, Velocity does not have a mechanism to define functions which return object references. Macros are really intended to be a shortcut to display text.
In cases like this, the way to proceed is generally to create a "tool" in Java and put an instance in the context. A tool is just an ordinary class with a method that returns what you are looking for
e.g.
create an object with an "eval" method, then put it in the context as "referenceEvaluator".
#set($obj = $referenceEvaluator.eval($objRef))
You might find that your code is clearer if you avoid the double evaluation and just insert an object into the context named $obj that does what you want. (better performance, too).