View mode: basic / threaded / horizontal-split · Log in · Help
July 19, 2012
Re: ufcs and integer params
On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote:
> The clear argument for me is that it must be trivial to take an 
> existing member variable and change it to a property
> function pair _and vice versa_.

I can see some value in that.

> The other bits about non-@property
> functions is significantly less important as far as I'm 
> concerned.


Question to everybody: how would you feel about this
compromise: the strictness is opt in.

So, if you don't use @property, you get the status quo.
These functions can be called either way, but if there's
ambiguity, it tends toward treating them as a function.

If you do use @property, it becomes strict.


This would cover your concerns while keeping the
dual-syntax benefits, and it minimizes code breakage
of existing stuff.


It'd also discourage a lot of the questions of to @property
or not to @property, since you can just ask "is it a real
property" without falsely marking stuff for UFCS chaining or
whatever. It'd save me a lot of headaches on my range.empty's
too.




If we switch to this compromise position, I'm about 98%
sure I'd vote yes (would have to actually try it to be certain).
July 20, 2012
Re: ufcs and integer params
Marco:

>>> auto distance = 100.km;
>>> auto speed = 120.km/hour;

>> Sounds fun. I mean, it makes me happy to see code written like this
instead of
>> Distance distance = new Kilometers(100);
>> Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new
Hours(1));

Yeah, that was exactly one of my goals :)

David:

> I find multiplication to read much more natural:
> ---
> enum km = kilo * meter;
>
> auto distance = 100.0 * km;
> auto speed = 100.0 * km / hour;
>
> auto timeToDest = distance / speed;
> ---

This is good too. I have code that autogenerate the SI-prefixed versions
(not on Github, I should clean it and push), but thought about offering
prefix functions by themselves. Hmm, looking at it, I guess kilo is just
1000 as an enum in your code? That's a good idea.

Anyway, multiplication is good, I just looked for an excuse to play with
UFCS :)

> See http://klickverbot.at/code/units/ for a slightly neglected
implementation of this scheme. It supports stuff like defining new units
with arbitrary (potentially runtime) conversion factors, properly
typechecked affine units (think degrees celsius), etc.

Ah good. I remembered someone posting something on units-checking, but
couldn't find the message. I also have something on celsius/kelvin and
wondered if I needed to go beyond affine, to fully generalize the concept.

Btw, is °C substraction authorized with your module, or multiplication? I
wondered what to forbid and what to authorize.

And I (re)discovered while browsing Wikipedia the numerous temperature
units I saw at school 15 years ago :)

> – but any error messages and symbol names will probably look like if the
compiler had a seizure.

why?
July 20, 2012
Re: ufcs and integer params
On Friday, 20 July 2012 at 12:28:52 UTC, Philippe Sigaud wrote:
> Hmm, looking at it, I guess kilo is just
> 1000 as an enum in your code? That's a good idea.

Sorry, that should have been »kilo!gram«. It actually creates a 
new unit with a conversion factor of 1000 relative to the base 
unit (well, it does a few more things to handle cases like 
kilo!(milli!meter)), with the point being that the quantities are 
actually stored in memory "verbatim", i.e. without being 
normalized to e.g. SI units. Making »kilo * gram« work would be 
easy, but I decided it could lead to confusing situations.

David
July 21, 2012
Re: ufcs and integer params
> Sorry, that should have been »kilo!gram«. It actually creates a new unit
> with tbua conversion factor of 1000 relative to the base unit (well, it does a
> few more things to handle cases like kilo!(milli!meter)), with the point
> being that the quantities are actually stored in memory "verbatim", i.e.
> without being normalized to e.g. SI units. Making »kilo * gram« work would
> be easy, but I decided it could lead to confusing situations.

At one time, I wanted to make kilo a factory function that would do
the same transformation as your kilo!gram (that is, kilo(milli(gramm))
would in fact return a gram), but I found the style to be too
different from the rest of the code (with value.kg and such).

Btw, how do you handle the fact that in SI, the mass unit is the
kilogram and not the gram?
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home