mohxa's equal function doesn't work with reference types about mohxa HOT 2 OPEN

For interest sake, I don't consider an array a "primitive" type (unlike the primitives of string, int, bool, float, that are treated by value and not reference). It would be useful to have an array equality test though I agree, I'll add one.

I'd be curious what your thoughts are on nested arrays. I think it would be useful to handle nested arrays of primitives - but it does bring up a question of ones not by value. I don't think that it's within scope to try and reason/infer things that the user already knows about the structure, if the test input is complex.

In other words, at some point, it makes more sense that you're transforming your test data into an easily testable form first. If the test data is complex you would have to write a comparison that understands it, rather than trying to make the library handle every situation for every user. I think this is an important balance.

For example, certain objects are an easy to for equality using haxe.Json.stringify, where you convert it to a string and compare the strings. But this approach doesn't work for all objects, so it's up to you to understand the data and coerce it as needed. The library won't be able to do that past a certain point without losing simplicity.

from mohxa.

Hello Sven, how are you?

To answer your question, I think what we want is a missing feature in haxe.

I would like to define an interface or a typedef, with a function eq.
Then we want our type to match this interface, so we implement for the
type with the static extension mechanism.
But currently in haxe, this is just syntactically, and will not really
treat the type as belonging to that interface or that typedef.

If there was a way in haxe to say: I want this type (even built in
types) to be an instance of that interface. (ideally, if it matches a
typedef, then it's part of that typedef, and will not mess with past
code or others' code)
haxe would reply: you can, but only if the type implements the
interface. we would then reply back: okay. give us a way to implement
it, as users, without relying on the source code.

The closest that I could figure is static extensions, however in the
extensions you have to rely on public definitions, and not have access
to everything. Perhaps the access macros may provide a better solution.

I believe it can be a good feature to have. I did try to do it but got
lost in generic land.
I thought a type can match an interface if it has everything of the
interface. so with static extensions I tried to implement the function.
but the interface is not something dynamic, and the class has to be
defined as such.

sorry for the long reply.
best regards, kobi

PS: I have some code ready, but I couldn't get it to be 100% what I wanted.
tell me if you're interested.

On 05/01/2016 06:30 AM, Sven Bergström wrote:

For interest sake, I don't consider an array a "primitive" type
(unlike the primitives of string, int, bool, float, that are treated
by value and not reference). It would be useful to have an array
equality test though I agree, I'll add one.

I'd be curious what your thoughts are on nested arrays. I think it
would be useful to handle nested arrays of primitives - but it does
bring up a question of ones not by value. I don't think that it's
within scope to try and reason/infer things that the user already
knows about the structure, if the test input is complex.

In other words, at some point, it makes more sense that you're
transforming your test data into an easily testable form first. If the
test data is complex you would have to write a comparison that
understands it, rather than trying to make the library handle every
situation for every user. I think this is an important balance.

For example, certain objects are an easy to for equality using
|haxe.Json.stringify|, where you convert it to a string and compare
the strings. But this approach doesn't work for all objects, so it's
up to you to understand the data and coerce it as needed. The library
won't be able to do that past a certain point without losing simplicity.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2 (comment)

from mohxa.