On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
> On a tangent, I need a name for the struct that will represent HSL/HSV/HSI/HCY.
> They're all basically identical, and might as well be a parameter to a
> shared type... but I can't think of a name for that type! >_<
> I can't reasonably call it any of those or it would be confused,
> rather, each of those would be an alias for an instantiation of each
> type.
> I'm thinking along the lines of PolarRGB? It's not really that though.
> I can't think of any other good names.
> alias HSL = PolarRGB!(Type.HSL);
>
> Naming things is so hard!

Since H(ue) seems to be the only shared property of all those RGB representations one of the following names might be acceptable:

HRGB
HueRGB
HueBasedRGB
HueOrientedRGB
HueTypeRGB

I'm not confident, though. :-(

Fool

On Wednesday, 24 June 2015 at 05:30:50 UTC, Manu wrote:
> Right, and this was what I had in mind.
> I think the average user would want to: import std.color, and that's
> it. They will probably want RGB8 or RGBA8.
> Most users will never touch anything else in the API, so using
> package.d as an "import absolutely everything" doesn't seem useful at all to me.


Hmm, yes, that's an interesting point.

> I'm in favour of trimming package.d though. What do you suggest?

Even if it doesn't actually import everything, I'd still prefer to keep the package.d pretty clear. Maybe move those bits out to std.color.common or std.color.foundation and public import that from the package?


On the other hand, if everybody is ok with the package.d itself being a minimal import, this isn't necessary, I am just really worried about it growing too big in the future.


> Surely the compiler won't eagerly resolve those aliases and instantiate all those colour types in the event they are never referenced?

It does:

struct Foo(T) { pragma(msg, T.stringof); }
alias foo = Foo!int;

dmd test.d
int

It printed the thing meaning the template did in fact get instantiated when the alias mentioned it.

Templates inside the type won't be instantiated, but regular methods will be - along with any templates *they* reference.


In the case of the color package, this is all pretty small and probably not a big deal, but I'm just trying to set expectations that others can follow too.

> I was very careful to limit run-away phobos dependencies.
> I really care about this, and I've tried to limit import scope in all locations.

Indeed, you did well.

On Wednesday, 24 June 2015 at 08:47:50 UTC, Manu wrote:
> Ah okay.
> Yeah, it's an interesting idea. It's only applicable to RGB colours.
> What's a bit awkward, is it's not entirely clear where the result of
> the swizzle is assigned? Is the result of the swizzle assigned to the
> colours present in the order of appearance in the current layout?
> BGR8 a = Color.white;
> BGR8 b = a.rbg;
>
> is that: b=r, g=b, r=g, or is it r=r, g=b, b=g? Surely it's the former, but that means you need to be conscious of the colour layout whenever you perform a swizzle; ie, it will do different things for different layouts...

Ahh yes, I didn't think of that. I think for the 99% of people who are just using RGBA8 everywhere, it would still be valuable. But if it didn't get in I wouldn't be too disappointed.

On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
> On a tangent, I need a name for the struct that will represent HSL/HSV/HSI/HCY.
> They're all basically identical, and might as well be a parameter to a
> shared type... but I can't think of a name for that type! >_<
> I can't reasonably call it any of those or it would be confused,
> rather, each of those would be an alias for an instantiation of each
> type.
> I'm thinking along the lines of PolarRGB? It's not really that though.
> I can't think of any other good names.
> alias HSL = PolarRGB!(Type.HSL);
>
> Naming things is so hard!

I don't like PolarRGB since it doesn't have a lot to do with RGB.

HueSpace!(Type.HSL) ?

On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:
> On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
>> On a tangent, I need a name for the struct that will represent HSL/HSV/HSI/HCY.
>> They're all basically identical, and might as well be a parameter to a
>> shared type... but I can't think of a name for that type! >_<
>> I can't reasonably call it any of those or it would be confused,
>> rather, each of those would be an alias for an instantiation of each
>> type.
>> I'm thinking along the lines of PolarRGB? It's not really that though.
>> I can't think of any other good names.
>> alias HSL = PolarRGB!(Type.HSL);
>>
>> Naming things is so hard!
>
> I don't like PolarRGB since it doesn't have a lot to do with RGB.
>
> HueSpace!(Type.HSL) ?

OK I take that back. HSL expresses color in the RGB space you're right. Maybe CylindricalRGB ? It's a volume after all.

On 25 June 2015 at 05:59, Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 24 June 2015 at 05:30:50 UTC, Manu wrote:
>>
>> Right, and this was what I had in mind.
>> I think the average user would want to: import std.color, and that's
>> it. They will probably want RGB8 or RGBA8.
>> Most users will never touch anything else in the API, so using
>> package.d as an "import absolutely everything" doesn't seem useful at all
>> to me.
>
>
>
> Hmm, yes, that's an interesting point.
>
>> I'm in favour of trimming package.d though. What do you suggest?
>
>
> Even if it doesn't actually import everything, I'd still prefer to keep the package.d pretty clear. Maybe move those bits out to std.color.common or std.color.foundation and public import that from the package?
>
>
> On the other hand, if everybody is ok with the package.d itself being a minimal import, this isn't necessary, I am just really worried about it growing too big in the future.
>
>
>> Surely the compiler won't eagerly resolve those aliases and instantiate all those colour types in the event they are never referenced?
>
>
> It does:
>
> struct Foo(T) { pragma(msg, T.stringof); }
> alias foo = Foo!int;
>
> dmd test.d
> int
>
> It printed the thing meaning the template did in fact get instantiated when the alias mentioned it.

Bugger! So an instantiation of the struct is one thing, will it also instantiate all the members and functions too? If it leads to an instantiation of the cast operator, then at that point, that's basically everything... the whole library is pulled.

What selective imports? Do selective imports of a single symbol from a module lead to the whole module being parsed and top level instantiations?


> Templates inside the type won't be instantiated, but regular methods will be - along with any templates *they* reference.

Regular methods will be, but not template methods?
Good, that means the cast operator will not be instantiated until it
is referenced. This is critical, that's the point that leads to
basically everything.
Ideally conv.d would only have selective imports at the top (if
there's an advantage to that) and proper imports scoped within the
various cast functions. Would that be a win, or will the selective
imports from each module at the top negate the advantage?


> In the case of the color package, this is all pretty small and probably not a big deal, but I'm just trying to set expectations that others can follow too.
>
>> I was very careful to limit run-away phobos dependencies.
>> I really care about this, and I've tried to limit import scope in all
>> locations.
>
>
> Indeed, you did well.

On 25 June 2015 at 07:05, Tofu Ninja via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 24 June 2015 at 08:47:50 UTC, Manu wrote:
>>
>> Ah okay.
>> Yeah, it's an interesting idea. It's only applicable to RGB colours.
>> What's a bit awkward, is it's not entirely clear where the result of
>> the swizzle is assigned? Is the result of the swizzle assigned to the
>> colours present in the order of appearance in the current layout?
>> BGR8 a = Color.white;
>> BGR8 b = a.rbg;
>>
>> is that: b=r, g=b, r=g, or is it r=r, g=b, b=g? Surely it's the former, but that means you need to be conscious of the colour layout whenever you perform a swizzle; ie, it will do different things for different layouts...
>
>
> Ahh yes, I didn't think of that. I think for the 99% of people who are just using RGBA8 everywhere, it would still be valuable. But if it didn't get in I wouldn't be too disappointed.

Sadly not, windows used BGR in basically all OS api's. Compatibility support usually required BGR too, since that was the only color format supported by old video hardware for a long time.

On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:
>>
>> On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
>>>
>>> On a tangent, I need a name for the struct that will represent
>>> HSL/HSV/HSI/HCY.
>>> They're all basically identical, and might as well be a parameter to a
>>> shared type... but I can't think of a name for that type! >_<
>>> I can't reasonably call it any of those or it would be confused,
>>> rather, each of those would be an alias for an instantiation of each
>>> type.
>>> I'm thinking along the lines of PolarRGB? It's not really that though.
>>> I can't think of any other good names.
>>> alias HSL = PolarRGB!(Type.HSL);
>>>
>>> Naming things is so hard!
>>
>>
>> I don't like PolarRGB since it doesn't have a lot to do with RGB.
>>
>> HueSpace!(Type.HSL) ?
>
>
> OK I take that back. HSL expresses color in the RGB space you're right. Maybe CylindricalRGB ? It's a volume after all.

They're not cylindrical, they each represent a different shape;
cylinder, hexacone, double-hexacone,
weird-warped-crooked-cube-on-its-corner ;)
They really are polar coordinates of a sort, although even that's not
really a good description, since it's a hex rather than a circle.
Perhaps the word 'angular' is more fitting than polar in this case...
but that doesn't get me any closer to a good name! >_<

Wikipedia at least refer to these as cylindrical colour spaces


On Thu, Jun 25, 2015 at 2:05 PM, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:
>>>
>>> On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
>>>>
>>>> On a tangent, I need a name for the struct that will represent
>>>> HSL/HSV/HSI/HCY.
>>>> They're all basically identical, and might as well be a parameter to a
>>>> shared type... but I can't think of a name for that type! >_<
>>>> I can't reasonably call it any of those or it would be confused,
>>>> rather, each of those would be an alias for an instantiation of each
>>>> type.
>>>> I'm thinking along the lines of PolarRGB? It's not really that though.
>>>> I can't think of any other good names.
>>>> alias HSL = PolarRGB!(Type.HSL);
>>>>
>>>> Naming things is so hard!
>>>
>>>
>>> I don't like PolarRGB since it doesn't have a lot to do with RGB.
>>>
>>> HueSpace!(Type.HSL) ?
>>
>>
>> OK I take that back. HSL expresses color in the RGB space you're right. Maybe CylindricalRGB ? It's a volume after all.
>
> They're not cylindrical, they each represent a different shape;
> cylinder, hexacone, double-hexacone,
> weird-warped-crooked-cube-on-its-corner ;)
> They really are polar coordinates of a sort, although even that's not
> really a good description, since it's a hex rather than a circle.
> Perhaps the word 'angular' is more fitting than polar in this case...
> but that doesn't get me any closer to a good name! >_<

I would probably go with "perceptual" or something like it


On Thu, Jun 25, 2015 at 2:39 PM, Danni Coy <danni.coy@gmail.com> wrote:
> Wikipedia at least refer to these as cylindrical colour spaces
>
>
> On Thu, Jun 25, 2015 at 2:05 PM, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:
>>>>
>>>> On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:
>>>>>
>>>>> On a tangent, I need a name for the struct that will represent
>>>>> HSL/HSV/HSI/HCY.
>>>>> They're all basically identical, and might as well be a parameter to a
>>>>> shared type... but I can't think of a name for that type! >_<
>>>>> I can't reasonably call it any of those or it would be confused,
>>>>> rather, each of those would be an alias for an instantiation of each
>>>>> type.
>>>>> I'm thinking along the lines of PolarRGB? It's not really that though.
>>>>> I can't think of any other good names.
>>>>> alias HSL = PolarRGB!(Type.HSL);
>>>>>
>>>>> Naming things is so hard!
>>>>
>>>>
>>>> I don't like PolarRGB since it doesn't have a lot to do with RGB.
>>>>
>>>> HueSpace!(Type.HSL) ?
>>>
>>>
>>> OK I take that back. HSL expresses color in the RGB space you're right. Maybe CylindricalRGB ? It's a volume after all.
>>
>> They're not cylindrical, they each represent a different shape;
>> cylinder, hexacone, double-hexacone,
>> weird-warped-crooked-cube-on-its-corner ;)
>> They really are polar coordinates of a sort, although even that's not
>> really a good description, since it's a hex rather than a circle.
>> Perhaps the word 'angular' is more fitting than polar in this case...
>> but that doesn't get me any closer to a good name! >_<