The interface abstraction seems to be violated by the "pass by value"
convention at the receiver when the "I/O" pattern is found to be
dysfunctional.
In [IO] https://go.dev/play/p/9vx4HZpSYe0
we see that the implementation of an exemplar interface is functionally
stateless, demonstrating the
Hi,
It occurs to me that GOPL type theory has a distinct benefit from its
constraint to the membership relation. The external derivation of type
semantics has particular constraint.
Tools parsing GOPL expressions and systems are more readily capable of
reproducing type semantics.
The benefit
> Full explanation here:
> https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have-variance-in/
>
> On Saturday 6 January 2024 at 11:55:27 UTC John Pritchard wrote:
>
>> Hi,
>>
>> Thinking about types and their conception, I could avoid the type
>> a
> TestObject("20231217190339"), TestObject("20231213155157"),
> TestObject("20231219065525"), TestObject("20231231120412"),
> TestObject("20231221152849"), TestObject("20240102073948"),
> TestObject("20240101083455")}
>
>
Hi,
Here's a case of "type dissonance" I don't understand. Why should it be?
https://github.com/syntelos/go-sort
An interface type not passing through a static public package function that
employs the interface.
type Comparable interface {
Compare(Comparable) int
}
func Sort(array
August 2023 at 14:05:49 UTC+1 John Pritchard wrote:
>
> I have a disparity between "go run" [
> https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
> and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
> Using go version 1.21.0.
>
>
>
Hi,
I have a disparity between "go run" [
https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
Using go version 1.21.0.
A fairly simple structure of type abstraction works on play.go.dev, but
fails to build.
Comments? Issue?
Hello,
Debugging "go build" with dlv, which hungup at
go/src/cmd/go/main.go:92:var _ = go11tag
Looking around a bit, found no particular rationale for the existence of
"go11tag".
Best,
John
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
