I want to define a custom type X in Slick 3 that should be Mapped to Option[String].
At the moment I'm trying to use MappedColumnType.base[X, Option[String]], but Option[String] does not seem to be a "BaseColumnType".
I know, that Option[X] would be possible, but I prefer the other way...
Related
I have a bunch of classes which carry out functionality, but with type hinting I wanted to now have it show an instance of that class, Or a list of instances of that class.
class Foo:
pass
class Bar:
pass
class Win:
pass
I then started seeing Typings, and was doing things like:
get_all_foos() -> list:
return []
which makes sense, but i wanted it to be more verbose. Something akin to:
get_all_foos() -> list<Foo>:
return []
I was looking online and it seems that I might need to use the LIST typing, instead of base list.
from typing import List
get_all_foo() -> List[Foo]:
pass
While I dont think i was getting any errors, I wanted to make sure this was the correct way to do things per Python standard or if it suitable to just do:
get_all_foo() -> list[Foo]:
pass
The answer, based on research on the python docs, is as follows.
A list is something which can be implemented. It is a datastructure.
A List is a typing, which is used for type hinting. It is not a datastructure.
For people familiar with other typed languages, my mistake was that I was mistaking a List also as an alternate Datastructure with a similar implementation of list.
So that means, that you can have a function:
get_all() -> List[Foo]: pass
BUT the return type can't be a List, for reasons stated above.
It would still be a list as that is the actual datastructure. it is purely for decorator purposes. I was having issues conceptually with the fact that I was trying to enforce typing by making things be a List as the samples were showing, but since it wasnt instantiable, it all made sense.
Therefore you would easily have
def get_all() -> List[Foo]: return []
which returns a list. I was thinking both the hint and return should be the same type.
Is it possible to define parameter for a type ? I want to have type that represents fixed length string but I dont want do define multiple such types for different lengths, that is TFixedString(N) so I could use TFixedString(2) and TFixedString(16).
No you can not do this. It is not supported in XSD.
I want to make a color map on vtkstructuredgrid and I need the colors to be interpolated between cells. The other option is using point data but when ever I use
structuredgrid->PointData()->SetScalars(Floatarray);
it says I cant have a pointer to a incomplete class type.
Any help would be greatly appreciated.
Your approach should work...
However, PointData is not a method, for the vtkStructuredGrid class: you should avoid (), and that's the reason for the error (Pointer to incomplete class type is not allowed).
Moreover, PointData is protected, in the "standard" definition of vtkStructuredGrid, and you should derive the entire class to access it from your code.
Before trying that, by the way, can you try with
structuredgrid->GetPointData()->SetScalars(Floatarray);
?
It should work too (not sure about the parameter type passed to SetScalar(), BTW).
I want to see if I can map Racket structure fields to columns in a DB.
I've figured out how to extract accessor functions from structures in PLT scheme using the fourth return value of:
(struct-type-info)
However the returned procedure indexes into the struct using an integer. Is there some way that I can find out what the field names were at point of definition? Looking at the documentation it seems like this information is "forgotten" after the structure is defined and exists only via the generated-accessor functions: (<id>-<field-id> s).
So I can think of two possible solutions:
Search the namespace symbols for ones that start with my struct name (yuk);
Define a custom define-struct macro that captures the ordered sequence of field-names inside some hash that is keyed by struct name (eek).
I think something along the lines of 2. is the right approach (define-struct has a LOT of knobs and many don't make sense for this) but instead of making a hash, just make your macro expand into functions that manipulate the database directly. And the syntax/struct library can help you do the parsing of the define-struct form.
The answer depends on what you want to do with this information. The thing is that it's not kept in the runtime -- it's just like bindings in functions which do not exist at runtime. But they do exist at the syntax level (= compile-time). For example, this silly example will show you the value that is kept at the syntax level that contains the structure shape:
> (define-struct foo (x y))
> (define-syntax x (begin (syntax-local-value #'foo) 1))
> (define-syntax x (begin (printf ">>> ~s\n" (syntax-local-value #'foo)) 1))
>>> #<checked-struct-info>
It's not showing much, of course, but this should be a good start (you can look for struct-info in the docs and in the code). But this might not be what you're looking for, since this information exists only at the syntax level. If you want something that is there at runtime, then perhaps you're better off using alists or hash tables?
UPDATE (I've skimmed too quickly over your question before):
To map a struct into a DB table row, you'll need more things defined: at least hold the DB and the fields it stand for, possibly an open DB connection to store values into or read values from. So it looks to me like the best way to do that is via a macro anyway -- this macro would expand to a use of define-struct with everything else that you'd need to keep around.
Is there any functionality in IDL that will allow it to evaluate a a string as code?
Or, failing that, is there a nice, dynamic way of including /KEYWORD in functions? For example, if I wanted to ask them for what type of map projection the user wants, is there a way to do it nicely, without large if/case statements for the /Projection_Type keyword it needs?
With even a small number of user options, the combinations would cause if/case statements to get out of hand very quickly to handle all the possible options.
The best bet is to use a case statement because you can't trust that your user is going to type in the same string for Projection_Type that you're expecting as in the keyword.
Though if you are set on doing something like this, there is the EXECUTE function that treats a string as an IDL statement:
Result = EXECUTE(String [, QuietCompile] [, QuietExecution])
Edited to add, there's also CALL_FUNCTION and CALL_PROCEDURE that are faster but maybe less flexible. Look them all up in the IDL help and see what works for you.