I have the following generic type definition:
# typed: true
class A
extend T::Sig
extend T::Generic
Value = type_member
sig { params(value: Value).void }
def initialize(value)
#value = value
end
sig { returns(Value) }
def value
#value
end
end
When I reveal the type of #value, I'm expecting it is Integer, but it's T.untyped:
v = A.new(42)
T.reveal_type(v.value) #=> Revealed type: T.untyped https://srb.help/7014
I understand it's possible to specify the type of the argument explicitly A[Integer].new(42), but that way I can't put keep type information separately in .rbi file.
What is the right way annotating generic types?
A[Integer].new(42) is the right way to specify generic type.
You probably expect sorbet to infer type Integer from the input (42). However, sorbet doesn’t work that way. You have to specify the generic type as A[Integer] and sorbet will use that to validate the type of the input (42) and output (#value) at run time.
I understand it's possible to specify the type of the argument explicitly A[Integer].new(42), but that way I can't put keep type information separately in .rbi file.
It is probably impossible to separate type construct (or sorbet construct) and your code cleanly like that for generic type. As you’d see even for T::Array or T::Hash, you also have to specify the type the same way. And for constant, you’d frequently need to use T.let.
Related
am using a protobuf definition file to create golang classes
file.proto
message my_message {
<what type to use?> data = 1 [json_name = "data"]
}
generated.go
type MyMessage struct {
data any
}
I have checked out Struct , Value and Any, though none of them actually mark the type as “any” in generated classes.
The closes I get is Value type which can accomodate primitives as well as structs and lists.
As far as I'm aware the Go code generator doesn't have any circumstances where any/interface{} will be used for a generated field.
google.protobuf.Any is likely what you want here, but the field in the generated code will of type anypb.Any. If you absolutely require the any type be used, you'll unfortunately have to manually map to another struct.
I need to specify a certain set of values as the expected return type for my function. Let's say there was defined some class called Scene which has attribute name which is supposed to be a string which may end only with "1K", "2K" or "4K". Now I want to write a function which takes this class as an argument and returns the last 2 characters of its name as a string. Is there a way to specify this function return type like a set of exact string values using built-in modules in Python 3.7.7? Something like this:
def scene_resolution(sc : Scene): -> any value in {'1K', '2K', '4K'}: # return type?
res = sc.name[-2:]
assert res in {'1K', '2K', '4K'}
return res
I know about using Literal from typing_extensions, but unfortunately it works only with Python 3.8 and higher, and the API of the soft I'm dealing with uses Python 3.7.7. I've also tried to make something with enum.Enum but could not make it work properly.
Do you have any suggestions?
UPD. The only way I found so far is to define some function that returns the set I need and use its name as expected return type. Not sure whether it is correct way and a good practice, but at least it works.
In Raku, HOWs must expose a list of archetypes through an archetypes method, which is used to determine what broader features of types a type implements, e.g. parametricity or composability. I noticed Metamodel::EnumHOW (the HOW used with enums) has the augmentable archetype, which is given to types that can be extended after composition with the augment keyword when the MONKEY-TYPING pragma is enabled.
My first guess at why enums would be augmentable would be to allow enum values to be added, so I tried writing this:
use v6;
use MONKEY-TYPING;
enum Foo <foo bar baz>;
augment enum Foo <qux>;
say qux;
But this throws:
bastille% raku test.raku
===SORRY!=== Error while compiling /home/morfent/test.raku
Redeclaration of symbol 'Foo'.
at /home/morfent/test.raku:5
------> augment enum Foo⏏ <qux>;
So they're probably not intended to be augmented in this way.
My next guess was that they're intended to be augmentable with regards to the enum values, not the enum type itself. augment, interestingly, doesn't take into account what HOW a type actually has when you tell it what kind of type you're augmenting, so I tried augmenting an enum like you would a class:
use v6;
use MONKEY-TYPING;
enum Foo <foo bar baz>;
augment class Foo {
proto method is-foo(::?CLASS:D: --> Bool:D) {*}
multi method is-foo(foo: --> True) { }
multi method is-foo(::?CLASS:D: --> False) { }
}
say foo.is-foo;
Which works:
bastille% raku test.raku
True
But this doesn't feel like how you're intended to augment enums to me. This usage of augment is rather weird, and there isn't any implication that this should be possible to do from its documentation. How are you intended to augment enums?
FAQ
Foo.is-foo doesn't appear to have any code? What is it doing?
is-foo is rather heavy-handed with how it uses features of signatures and parameters. It depends on the following:
Constant values may be used like types in signatures. This includes enum values, which are dealt with at compile-time.
A routine can be made to always return a constant value by making one its signature's return value's type.
Variables for any given parameter in a signature are optional.
When a colon is placed after the first parameter like this, that first parameter is the signature's invocant. In the case of methods, this allows you to type self however you want.
::?CLASS is an alias for the class whose scope a method is declared in. This exists in class and role bodies, so despite Foo not really being a class, that is what the symbol is referring to.
:D is a type smiley denoting that a type should only typecheck against its own instances, not type objects that typecheck like it.
Since foo is a more specific type than ::?CLASS:D (an alias for Foo:D), when invoking this method on foo, the foo multi will be selected and True will get returned, but in any other case, the ::?CLASS:D multi will be selected and False will be returned.
In Java you can add almost arbitrary attributes and functions to enums. So I do think augment in the way you describe could make sense. For example:
use MONKEY-TYPING;
enum Days(Monday => 1, Tuesday => 2, Wednesday => 3, Thursday => 4, Friday => 5, Saturday => 6, Sunday => 7);
augment class Days {
proto method is-weekend(::?CLASS:D: --> Bool:D) {*}
multi method is-weekend(Saturday: --> True) { }
multi method is-weekend(Sunday: --> True) {}
multi method is-weekend(::?CLASS:D: --> False) { }
proto method days-til-weekend(::?CLASS:D: --> Int:D) {*}
# there is probably a better way to express this, but
# hopefully the concept is clear
multi method days-til-weekend(Monday: --> 4) {}
...
}
say Monday.is-weekend;
say Wednesday.days-til-weekend;
say Saturday.is-weekend;
I get cannot use map[string]MyType literal (type map[string]MyType) as type map[string]IterableWithID in argument to MapToList with the code below, how do I pass in a concrete map type to method that expects a interface type?
https://play.golang.org/p/G7VzMwrRRw
Go's interface convention doesn't quite work the same way as in, say, Java (and the designers apparently didn't like the idea of getters and setters very much :-/ ). So you've got two core problems:
A map[string]Foo is not the same as a map[string]Bar, even if Bar implements Foo, so you have to break it out a bit (use make() beforehand, then assign in a single assignment).
Interface methods are called by value with no pointers, so you really need to do foo = foo.Method(bar) in your callers or get really pointer-happy to implement something like this.
What you can do to more-or-less simulate what you want:
type IterableWithID interface {
SetID(id string) IterableWithID // use as foo = foo.SetID(bar)
}
func (t MyType) SetID(id string) IterableWithID {
t.ID = id
return t
}
...and to deal with the typing problem
t := make(map[string]IterableWithID)
t["foo"] = MyType{}
MapToList(t) // This is a map[string]IterableWithID, so compiler's happy.
...and finally...
value = value.SetID(key) // We set back the copy of the value we mutated
The final value= deals with the fact that the method gets a fresh copy of the value object, so the original would be untouched by your method (the change would simply vanish).
Updated code on the Go Playground
...but it's not particularly idiomatic Go--they really want you to just reference struct members rather than use Java-style mutators in interfaces (though TBH I'm not so keen on that little detail--mutators are supes handy to do validation).
You can't do what you want to do because the two map types are different. It doesn't matter that the element type of one is a type that implements the interface which is the element type of the other. The map type that you pass into the function has to be map[string]IterableWithID. You could create a map of that type, assign values of type MyType to the map, and pass that to the function.
See https://play.golang.org/p/NfsTlunHkW
Also, you probably don't want to be returning a pointer to a slice in MapToList. Just return the slice itself. A slice contains a reference to the underlying array.
The Go Tour says the following:
You can only declare a method with a receiver whose type is defined in the same package as the method. You cannot declare a method with a receiver whose type is defined in another package (which includes the built-in types such as int).
Is there a reason for this other than avoiding everyone building their own methods off int and string? I've Googled around, but can't find anything referencing it.
The reason is that if you could define methods on other packages' types, you could modify the behavior of other packages. This is because the method set of a given type can have an effect on how values of that type are used.
Consider, for example, the fmt.Println function. When you pass an argument to fmt.Println, it will print a string representation of that value based on a set of rules. One of those rules is that if the type of the value has a String() string method (that is, it implements the fmt.Stringer interface), then that method will be called in order to obtain the string representation of the value.
Thus, imagine that we have a package, foo, and that package has a type, FooInt, defined as follows:
type FooInt int
Now imagine that this package also has a function, PrintFooInt:
func PrintFooInt(f FooInt) { fmt.Println(f) }
This will print the integer value of f. But let's say that you (in a different package, say main) were able to add methods to FooInt. Then you could do this:
func (f FooInt) String() string { return "foobar!" }
This would actually change the behavior of foo.PrintFooInt, which shouldn't be possible from outside the package.