Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashcleanup #278

Merged
merged 0 commits into from
Feb 25, 2016
Merged

Hashcleanup #278

merged 0 commits into from
Feb 25, 2016

Conversation

commy2
Copy link
Contributor

@commy2 commy2 commented Feb 25, 2016

replaces #238
everyone should be able to edit this now

@commy2 commy2 added this to the 2.3.2 milestone Feb 25, 2016
@nicolasbadano
Copy link
Contributor

@commy2, what about changing the underlying structure to use CBA_fnc_createNamespace? fnc_hashEachPair could be based on allVariables which support locations.

@commy2
Copy link
Contributor Author

commy2 commented Feb 25, 2016

hashes can use key different from strings, which is a benefit.
We can internally replace all hashes that only use strings as keys with createNamespace though (as long as they are not used in ui, i.e. the main menu)

@nicolasbadano
Copy link
Contributor

hashes can use key different from strings, which is a benefit.

oh, that's true. although using str(_object)as key could also work for almost all cases.

We can internally replace all hashes that only use strings as keys with createNamespace though (as long as they are not used in ui, i.e. the main menu)

Yes, that's a much safer alternative, although it's obviously much more work.

@nicolasbadano
Copy link
Contributor

Another possible alternative would be to add a second set of functions for "FastHashes", that only support string keys.

@nicolasbadano
Copy link
Contributor

Another possible alternative would be to add a second set of functions for "FastHashes", that only support string keys.

Besides, for the first time in CBA those would be REAL hashed dicts

@commy2
Copy link
Contributor Author

commy2 commented Feb 25, 2016

str(_object) is not reliable. It changes when the vehicle var name changes or when the object switches locality (#remote tag)

@PabstMirror
Copy link
Contributor

location hashes are local only (I don't think you can publicVariable a location)
I think ACRE has some stuff to serialze them, but it's not trivial.

@commy2
Copy link
Contributor Author

commy2 commented Feb 25, 2016

ed was trying to convert objects to strings.

@nicolasbadano
Copy link
Contributor

Yeah, you are right. Porting current CBA Hashes to CBA_fnc_createNamespace doesn't seem viable. Creating API calls for real hashes that coexist with the current ones would be a better solution.

@commy2
Copy link
Contributor Author

commy2 commented Feb 25, 2016

Real hashes as in using LOCATIONS with string keys? Converting objects to strings?

Two LOCATIONS can do the trick by making the object key the value of a string key LOCATION.

@nicolasbadano
Copy link
Contributor

Real hashes as in using LOCATIONS with string keys?

yes

Converting objects to strings? Two LOCATIONS can do the trick making the object key the value of a string key LOCATION.

I don't think that'd work reliably

@commy2 commy2 added the WIP label Feb 25, 2016
@commy2
Copy link
Contributor Author

commy2 commented Feb 25, 2016

PR still has the same problems as the other one, tag WIP

@commy2 commy2 merged commit e6abdff into master Feb 25, 2016
@thojkooi thojkooi deleted the hashcleanup branch April 25, 2016 11:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants