While some built-in types Int Float Bool are declared on Baiscs module, I couldn't find the declaration List type from List module accordingly. How could the default import List exposing (List) even work?
The List type is built into the language itself. You can see the JavaScript source code in Elm/Kernel/List.js
Related
I have question regarding about the onStrike variable. I declare onStrike in UnionEmployee as: var onStrike = False. Then, I go to the main function and create an object of UnionEmployee as x, but when I want to set x.onStrike = true it says
unresolved referrence
Is there a way to fix this?
One possible reason is that your list is not MutableList<UnionEmployee>, but a list of some UnionEmployee's supertype, for example just MutableList<Employee>. This could explain why you can successfully add a UnionEmployee there and call work method on an item of this list. If this is the case, then you should either declare your list as MutableList<UnionEmployee> or cast the obtained item to UnionEmployee if you're sure it will be of this type:
(list[3] as UnionEmployee).onStrike = true
Another explanation depends on whether UnionEmployee is written in Java or in Kotlin. If it's in Java, then getOnStrike/setOnStrike java methods are accessible in Kotlin as a property onStrike. If the class is in Kotlin, then these functions should be called from Kotlin as they were declared -- i.e. as functions. If you want a property in a Kotlin class, you should declare it as a property.
How can I put what a method - in this example get_properties - is giving me into a local variable when the type of the parameter is ANY?
"ES_ATTRIBUTES Exporting Type ANY
some_object->get_properties( IMPORTING es_attributes = ????? ).
I tried to put it into this variable, but that didn't work:
FIELD-SYMBOLS:
<ls_attributes> TYPE any.
In ABAP, it means that you may use a data object of any type (the simplest way is to declare it with DATA).
But it may be more restrictive according to the way the developer has coded his method.
Here, I recognize a method of WebUI Components (CRM, SOLMAN, …) so the data object must correspond to the "some_object" you are accessing. Do a debug of GET_PROPERTIES if you are not sure.
Actually as a caller, you should know the type you want to import for this ANY parameter.
You have to know the protocol of GET_PROPERTIES and debug it to know the return type of the parameter. In your method, you create a DATA REFERENCE and have it assigned to a ANY field symbol.
Data:
lr_data type ref to data.
Field-symbols:
<lt_properties> type any.
create data lr_data type TYPE_NAME. 'You should know the type
assign lr_data->* to <lt_properties>.
From my personal view, it is not a very good practice to define a method with EXPORTING parameter type ANY.
You either define a interface with IF_**_PROPERTY and you have a return TABLE of this interface.
or you return a name-value pair table. (From the method signature, it should return a TABLE, GET_PROPERTIES).
What I wan't to do is pretty much this:
type alias String =
{ prop: String -- here I want a native String
}
This won't work since the compiler naturally assumes it's recursive. I assumed some module would expose the native type, but neither Basics.String nor String.String works.
So, is there a way to have your own types use the same name as a native type and still reference the native one?
I'm not really sure this is a great idea, from a readability perspective, but to address the question of whether it's possible, it will work if you create an alias for String in a different module.
Something like this will work:
Alias.elm
module Alias exposing (..)
type alias ElmString =
String
Main.elm
module Main exposing (..)
import Alias exposing (ElmString)
type alias String =
{ prop: ElmString
}
I would like to have my own implementation of an existing module but to keep a compatible interface with the existing module. I don't have a module type for the existing module, only an interface. So I can't use include Original_module in my interface. Is there a way to get a module type from an interface?
An example could be with the List module from the stdlib. I create a My_list module with exactly the same signature than List. I could copy list.mli to my_list.mli, but it does not seem very nice.
In some cases, you should use
include module type of struct include M end (* I call it OCaml keyword mantra *)
rather than
include module type of M
since the latter drops the equalities of data types with their originals defined in M.
The difference can be observed by ocamlc -i xxx.mli:
include module type of struct include Complex end
has the following type definition:
type t = Complex.t = { re : float; im : float; }
which means t is an alias of the original Complex.t.
On the other hand,
include module type of Complex
has
type t = { re : float; im : float; }
Without the relation with Complex.t, it becomes a different type from Complex.t: you cannot mix code using the original module and your extended version without the include hack. This is not what you want usually.
You can look at RWO : if you want to include the type of a module (like List.mli) in another mli file :
include (module type of List)
I am trying to use pointers to create links between objects. Using Fortran and here is the code piece:
module base_pars_module
type,abstract,public :: base_pars
end type
end module
module test_parameters_module
use base_pars_module
type, extends(base_pars) :: test_pars
contains
procedure :: whoami
end type
contains
function whoami(this) result(iostat)
class( test_pars) :: this
write(*,*) 'i am a derived type child of base_pars'
end type
end module
module base_mask_module
use base_pars module
type, abstract , public :: base_mask
class(base_pars),pointer :: parameters
end type
end module
module test_mask_module
use base_mask_module
implicit none
type, extends(base_mask) :: test_mask
end type
end module
program driver
type(test_pars) , target :: par_Test
type(test_mask) :: mask_test
iostat= par_test%whoami()
mask_test%parameters=>par_test
iostat=mask_test%parameters%whoami()
end program
parameters at base_mask_module is a pointer with base_pars class. I would like to use this pointer to refer par_test object which is test_pars type that extends base_pars type. So the pointer and the target has the same class. But when I compile this it gives an error:
driver.f90:17.37:
iostat=mask_test%parameters%whoami()
1
Error: 'whoami' at (1) is not a member of the 'base_pars' structure
Is it a bug or am i doing something wrong?
When you have polymorphism like this there are two things to consider about an object: its dynamic type and its declared type. The parameters component of test_mask (base_mask) is declared as
class(base_pars),pointer :: parameters
Such a component therefore has declared type base_pars.
Come the pointer assignment
mask_test%parameters=>par_test
mask_test%parameters has dynamic type the same as par_test: test_pars. It's of declared type base_pars, though, and it's the declared type that is important when we care about its components and bindings. base_pars indeed has no whoami.
You need, then, something which has declared type par_test. Without changing the definitions of the derived types you can do this with the select type construct.
select type (pars => mask_test%parameters)
class is (par_test)
iostat=pars%whoami() ! pars of declared type par_test associated with mask_test%parameters
end select
That said, things get pretty tedious quite quickly with this approach. Always using select type, distinguishing between numerous extending types, will be quite a bind. An alternative would be to ensure that the declared type base_pars has a binding whoami. Instead of changing the main program as above, we alter the module base_pars_module:
module base_par_modules
implicit none ! Encourage good practice
type,abstract,public :: base_pars
contains
procedure(whoami_if), deferred :: whoami
end type
interface
integer function whoami_if(this)
import base_pars ! Recall we're in a different scope from the module
class(base_pars) this
end function
end interface
end module
So, we've a deferred binding in base_pars that is later over-ridden by a binding in the extending type test_pars. mask_test%parameters%whoami() in the main program is then a valid and the function called is that offered by the dynamic type of parameters.
Both approaches here address the problem with the binding of the declared type of parameters. Which best suits your real-world problem depends on your overall design.
If you know that your hierarchy of types will all have enough in common with the base type (that is, all will offer a whoami binding) then it makes sense to go for this second approach. Use the first approach rather when you have odd special cases, which I'd suggest should be rare.