Properties on anonymous types in TypeScript - typescript2.0

I am trying to check a property on an anonymous type in a Lambda expression in TypeScript.
This won't compile:
Build: Property 'infomodel' does not exist on type '{}'.
The sn.app.map.Markers array is of type any

Related

Where is the type of List declared in Elm?

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

What is the list of valid #SuppressWarnings warning names in Gosu?

What is the list of valid #SuppressWarnings warning names in Gosu?
The bit that comes in between the ("") in #SuppressWarnings("").
There is already an SO answer for Java but I'm interested in suppressing the warning that my variable type can be inferred (passing an inferred block variable as a function parameter does not compile so I'm using an explicitly typed variable).
Java answer: What is the list of valid #SuppressWarnings warning names in Java?

Embed an type of other pkg into mine, and init it by literal

I read how to init embed type, and a related Q&A.
What my problem is when compile this code, I got :
[Error] unknown field 'feature.DefaultSshHelper' in struct literal of type dala02
type FDH feature.DefaultSshHelper
type dala02 struct {
Md5_v string
feature.DefaultSshHelper
//FDH
}
var x_01_h1_p = &dala02{
Md5_v: "",
feature.DefaultSshHelper: feature.DefaultSshHelper{
//FDH: FDH{
// blabla
},
}
// use it by a interface []feature.CmdFioHelper{x_00_h1_p}
At first time, I thought it was an Exported problem, so I added this line 'type FDH feature.DefaultSshHelper'. Now, we have this error :
[Error] cannot use x_01_h1_p (type *dala02) as type feature.CmdFioHelper in array or slice literal:
*dala02 does not implement feature.CmdFioHelper (missing Getnextchecker method)
But a pointer of feature.DefaultSshHelper does implement feature.CmdFioHelper ( a interface ). So pointer of dala02 should also implement that, right? (reference form effective go)
There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one.
Question is how to fix this compile error, which line is wrong? I'm not a expert for golang, thanks for your advice :). BTW I do find some workaround.
When you refer to embedded fields, you have to leave out the package name of the embedded type, as the unqualified type name acts as the field name.
Spec: Struct types:
A field declared with a type but no explicit field name is an anonymous field, also called an embedded field or an embedding of the type in the struct. An embedded type must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type. The unqualified type name acts as the field name.
So simply write:
var x_01_h1_p = &dala02{
Md5_v: "",
DefaultSshHelper: feature.DefaultSshHelper{
// blabla
},
}
Your other attempt type FDH feature.DefaultSshHelper falls short as this type declaration creates a new type with zero methods: the type FDH does not "inherit" the methods of feature.DefaultSshHelper. And thus any type that embeds FDH will also lack methods of feature.DefaultSshHelper.

How to create and use array of type extensions in Fortran? [duplicate]

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.

I cannot understand how Dart Editor analyze source code

Dart Editor version 1.2.0.release (STABLE). Dart SDK version 1.2.0.
This source code produces runtime exception.
void main() {
test(new Base());
}
void test(Child child) {
}
class Base {
}
class Child extends Base {
}
I assumed that the analyzer generates something like this.
The argument type 'Base' cannot be assigned to the parameter type 'Child'
But I can only detect this error at runtime when occurred this exception (post factum).
Unhandled exception:
type 'Base' is not a subtype of type 'Child' of 'child'.
The analyzer is following the language specification here.
It only warns if a the static type of the argument expression is not assignable to the type of function the parameter.
In Dart, expressions of one type is assignable to variables of another type if either type is a subtype of the other.
That is not a safe type check. It does not find all possible errors. On the other hand, it also does not disallow some correct uses like:
Base foo = new Child();
void action(Child c) { ... }
action(foo); // Perfectly correct code at runtime.
Other languages have safe assignment checks, but they also prevent some correct programs. You then have to add (unsafe/runtime checked) cast operators to tell the compiler that you know the program is safe. It's a trade-off where Dart has chosen to be permissive and avoid most casts.
Let's try to be polite and answer the question without any prejudice.
I think I understand what you expected and here my angle on what the error means:
You are invoking the method with the argument of type Base
The method is expecting an argument of type Child
The Child is not equal to the Base, neither is a subtype of it (as a fact it is the Child that is a subtype of the Base)
It is working as expected as it makes only sense to provide object of the expected type (or it's subtypes - specialisations).
Update:
After reading again your question I realised that you are pointing out that editor is not finding the type problem. I assume this is due to the point that Dart programs are dynamic and hence certain checks are not done before the runtime.
Hope it helps ;-)