mohxa's equal function doesn't work with reference types

[kobi2187]

Hi! it seems the equal function only works with basic (primitive) types. I suspect that it checks reference equality, but it needs something like structural equality. for example:

equal([1,2,3],[1,2,3]); // returns false 

especially for unit testing, the user provides the expected values. so the reference cannot be the same.

[ruby0x1]

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.

[kobi2187]

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 https://github.com/underscorediscovery/mohxa/issues/2#issuecomment-216012470