[WIP] refactor UUID

[aheev]

This PR merges structs uuid and UUID. There's no point in having a separate class just to store static helper methods

resurrecting #243

Depends on LadybugDB/ladybug-python#1

[adsharma]

There's no point in having a separate class just to store static helper methods

https://claude.ai/chat/e6d3ba25-6688-489d-98ff-fdfa839725cc

I suspect it was done this way to have a stable ABI for uuid.

[aheev]

There's no point in having a separate class just to store static helper methods

https://claude.ai/chat/e6d3ba25-6688-489d-98ff-fdfa839725cc

I suspect it was done this way to have a stable ABI for uuid.

I don't have access to the chat

[adsharma]

Anthropic having a bad day. Hit or miss on a publicly shared URL in an incognito browser. May be try again in 10 mins.

Here's the key part:

This pattern separates the data layout from the API surface, and it's a common C++ design technique. Here's why someone would do it:

1. ABI Stability

The inner uuid struct with int128_t value is a plain-old-data (POD) type with a fixed, predictable memory layout. The outer UUID class provides the public interface. If you need to add methods, change behavior, or refactor internals, you can do so without breaking the binary interface — the underlying data layout stays the same.

2. The LBUG_API Export Macro

This macro typically expands to something like __declspec(dllexport/dllimport) on Windows or visibility attributes on Linux. Marking the whole UUID class with it exports all its methods from a shared library (.dll/.so). The inner uuid struct doesn't need this because it's just data — no vtable, no methods to export.

3. Separation of Concerns

• uuid = pure storage, trivially copyable, no dependencies, can be used in C-compatible contexts or passed across FFI boundaries
• UUID = rich C++ wrapper with formatting, parsing, comparison operators, serialization, etc.

[aheev]

Anthropic having a bad day. Hit or miss on a publicly shared URL in an incognito browser. May be try again in 10 mins.

Here's the key part:

This pattern separates the data layout from the API surface, and it's a common C++ design technique. Here's why someone would do it:

1. ABI Stability

The inner uuid struct with int128_t value is a plain-old-data (POD) type with a fixed, predictable memory layout. The outer UUID class provides the public interface. If you need to add methods, change behavior, or refactor internals, you can do so without breaking the binary interface — the underlying data layout stays the same.

2. The LBUG_API Export Macro

This macro typically expands to something like __declspec(dllexport/dllimport) on Windows or visibility attributes on Linux. Marking the whole UUID class with it exports all its methods from a shared library (.dll/.so). The inner uuid struct doesn't need this because it's just data — no vtable, no methods to export.

3. Separation of Concerns

• uuid = pure storage, trivially copyable, no dependencies, can be used in C-compatible contexts or passed across FFI boundaries
• UUID = rich C++ wrapper with formatting, parsing, comparison operators, serialization, etc.

Understood. Thanks!!