Guys, it's not about generating GUID/UUID from the code. I'm requesting a simple and well-defined thing for the well defined purpose and I'm getting answers based on some false assumptions.
Let's go thought this again:
GUID/UUID simple definition:
Stands for "Globally Unique Identifier." A GUID is a 128-bit (16 byte) number used by software programs to uniquely identify the location of a data object.
I still don't see what the problem is if there are multiple LABELs. If you only wish to use one of them, what problem is a few, or even, hundred others?
- when the GUID/UUID is added to the component, it's a uniquely identifier of this component and this component only. If there are more than one GUID/UUID then both of them can be used to identify component. Looking at the context of the component, it can be identified by two different GUIDs/UUIDs so the
identification is not unique. Not fulfilling this fundamental condition can't be ignored. You can't call it GUID/UUID and describe it like "och it's GUID/UUID but assign as many as you want because code allows to do it".
Practical implication are going even further: if a component can have more than GUID/UUID, then people will be confused about it's purpose. How I could write a component dependency if one component will have 5 GUID/UUID! Which one I should place my beat? There are no guaranties that the mod author won't remove the one I've chosen "because I can!" But if there is ONE GUID/UUID for ONE component it won't be a problem because the purpose of it is clear and there is no point of even looking at the GUID/UUID after adding it to the component code.
You don't really think literally made-up LABELs is a problem, do you? If a mod reports a LABEL as Foo, Foo is going to be valid.
Of course it's a problem. Labels like "MyFavoriteItems" are dangerous because two or more mod authors could use the same label. It would denies it's purpose. And arbitrary strings cannot be validated. Se below answer.
But to discuss you idea: you are essentially proposing a hash function that generates short hash values. But you don't specify what should be hashed in order to generate this value. How should different authors be prevented from hashing the same thing and getting the same hash values? The uniqueness metrics only deal with the probability of different things resulting in the same hash value. Identical things are always going to give the same value.
No, that is not something I've requested. I requested new KEYWORD called GUID or UUID, define it's requirements and purpose. I've posted examples about implementation but I think that looking at the
http://hashids.org might be the reason why you assume that I'm requesting hash function. I'm not, it was just a link to code examples for code/decode examples.
So let me use example (for this example, forget about my requirements that it should be much shorter):
1. open
http://guid.us/ and copy GUID - you will have a properly generated GUID ( I need a way to make it shorted, let's skip this requirements for now)
Here is your new GUID:8b97a0a3-048b-45db-8c4a-97f040448244
2. open
http://guid.us/Test/GUID paste GUID and click validate - you will have a properly validated GUID
GUID Test results:
Yes, that is GUID!
Here it is right back at you: 8b97a0a3-048b-45db-8c4a-97f040448244
Viola! We have a way to generate GUID and a way to validate it. Validation of the GUID will ensure that it was properly generated and eliminate the chance of the same GUID/UUID for multiple components.
You want something that can be used to refer to components that is not component numbers, because over a sufficiently large data set, components change over time. That's LABEL. I can't do different implementations for everyone simply because the current implementation is not to someone's liking. Sure, if there are technical shortcomings that prevent the feature from fulfilling its purpose, that's different, but so far I don't think you've raised any? (That would not apply equally to GUIDs.) Feel free to correct me if you have.
It's not about liking, it's about that LABEL doesn't work as I want. I've posted many technical shortcomings that prevent the feature from fulfilling its purpose:
- I have given the condition that it must be one, unique GUID/UUID
- I have given the condition that GUID/UUID can't be some arbitrary strings because they must be validated in order to check if it's a real GUID/UUID
- I have given the condition that GUID/UUID should be required for every component
- I have given the condition that GUID/UUID should be added to weidu.log
- also, LABEL was used by mod authors before for completely different purpose and context that GUID/UUID will be used
EDIT: Now I'm also adding new requirement which I forgot to mention because It was oblivious for me: FORBID_COMPONENT, MOD_IS_INSTALLED and possible in the future INCOMPATIBLE_COMPONENT from this topic:
http://forums.pocketplane.net/index.php/topic,29642.0.html should be able to use GUID/UUID
LABEL doesn't provide any of those features. If those aren't "technical shortcomings that prevent the feature from fulfilling its purpose" that I don't know what else I could say. This feature is the foundation of
effective BWS replacement,
effective mod database and the
effective solution for mod authors to write their own conflicts inside tp2 because component conflicts can't relay at the DESIGNATED as I proven via examples from first post of this topic.
Wisp, can you step into my boots and see my requests from external systems perspective?