View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: ufcs and integer params
Having been around long enough to remember when the ability to 
call "foo()" as "foo" first appeared, I feel it necessary to 
point out that this was *not* in fact a deliberate design, but 
rather a sort of "accident" that arose out of D's first attempt 
at properties.  It was the same "accident" loaded compiler 
release that gave us pseudo-members -- the precursors to UFCS.

The community discovered that these things were accepted by the 
compiler -- which was actually against the language spec at the 
time -- and further that the resulting code did the intuitively 
correct thing.  Response to the "accidents" being generally 
positive, it was decided to work toward making them legitimate 
language features.  Some flavor of @property (or of a certain 
other proposal which was a mimicry of C# properties... I was in 
that camp) has been in the plan ever since.

I find the ongoing debate/discussion of @property and -property 
to be... well, moot.  But hey, I'm just one crazy among an army 
of crazies.

-- Chris NS
July 16, 2012
Re: ufcs and integer params
On 07/16/2012 10:55 AM, Chris NS wrote:
> Having been around long enough to remember when the ability to call
> "foo()" as "foo" first appeared, I feel it necessary to point out that
> this was *not* in fact a deliberate design, but rather a sort of
> "accident" that arose out of D's first attempt at properties.

Afaik this first attempt was implemented roughly as designed. It is my
understanding that @property was added later in order to fix the
introduced ambiguities.

> It was the same "accident" loaded compiler release that gave us pseudo-members --
> the precursors to UFCS.
>

I still wonder how that could possibly happen.

> The community discovered that these things were accepted by the compiler
> -- which was actually against the language spec at the time -- and
> further that the resulting code did the intuitively correct thing.
> Response to the "accidents" being generally positive, it was decided to
> work toward making them legitimate language features. Some flavor of
> @property (or of a certain other proposal which was a mimicry of C#
> properties... I was in that camp)

That would certainly be more pretty -- OTOH it is hard to think of a
way to extend this to UFCS that is as natural as what happens if
everything is conflated in functions.

> has been in the plan ever since.
>
> I find the ongoing debate/discussion of @property and -property to be...
> well, moot. But hey, I'm just one crazy among an army of crazies.
>

Well, this newsgroup has the property that the stuff that is actually
important is usually unilaterally agreed upon rather quickly. :o)
July 16, 2012
Re: ufcs and integer params
I'm another who is /vehemently/ against the utter
idiocy that is the -property switch.

I wonder: if we had another poll, a recall election
if you will, how many people who said "yes" the
first time would change their minds now?

I betcha it'd be quite a few.
July 17, 2012
Re: ufcs and integer params
On Monday, 16 July 2012 at 23:13:54 UTC, Timon Gehr wrote:
> On 07/16/2012 10:55 AM, Chris NS wrote:
>> Having been around long enough to remember when the ability to 
>> call
>> "foo()" as "foo" first appeared, I feel it necessary to point 
>> out that
>> this was *not* in fact a deliberate design, but rather a sort 
>> of
>> "accident" that arose out of D's first attempt at properties.
>
> Afaik this first attempt was implemented roughly as designed. 
> It is my
> understanding that @property was added later in order to fix the
> introduced ambiguities.

Effectively yes, this is why I put "accident" in quotes.  The 
accidental part was that it was inadvertently extended to 
functions that it should not have been.  Free functions, for 
example, were not really supposed to be callable in that way... 
it has turned out to sometimes be a nice and useful thing, of 
course, but it wasn't exactly the goal at the time.  The goal was 
simply class/struct/union member functions that could be swapped 
out for exposed fields, or vice versa, without any change in user 
code.

>> It was the same "accident" loaded compiler release that gave 
>> us pseudo-members --
>> the precursors to UFCS.
>>
>
> I still wonder how that could possibly happen.

You, me, and everyone else.  I recall even Walter being a bit 
surprised by it and reviewing his code afterward.  The oddity was 
identified, but at the same time (almost-) everyone rather liked 
it and it stuck.  At the time I was maintaining an extensive 
library of array extensions, a spiritual ancestor to today's 
std.algorithm and std.range.  (None of that code is in Phobos, 
mind you, but it served a similar purpose.)  It was sort of like 
finding a peppermint in an old coat pocket.

>
>> The community discovered that these things were accepted by 
>> the compiler
>> -- which was actually against the language spec at the time -- 
>> and
>> further that the resulting code did the intuitively correct 
>> thing.
>> Response to the "accidents" being generally positive, it was 
>> decided to
>> work toward making them legitimate language features. Some 
>> flavor of
>> @property (or of a certain other proposal which was a mimicry 
>> of C#
>> properties... I was in that camp)
>
> That would certainly be more pretty -- OTOH it is hard to think 
> of a
> way to extend this to UFCS that is as natural as what happens if
> everything is conflated in functions.

As I recall, that was essentially how the discussion went back 
then, too.  I still like the C# style, personally, but I've found 
@property to be plenty usable, and even admittedly a bet more 
terse.

>> has been in the plan ever since.
>>
>> I find the ongoing debate/discussion of @property and 
>> -property to be...
>> well, moot. But hey, I'm just one crazy among an army of 
>> crazies.
>>
>
> Well, this newsgroup has the property that the stuff that is 
> actually
> important is usually unilaterally agreed upon rather quickly. 
> :o)

Yeah... usually.  ;)  I rarely speak up anymore, since I just 
don't have the time to commit to proving concepts and whatnot 
anymore.  "I'm old, Dean.  So very old."  I remember proposing a 
foreach statement (opApply was Walter's idea, though).  I also 
remember the horror that was the 'instance' keyword... man do I 
ever love that beautiful !() operator now, no matter what anyone 
else says about it.  Ultimately, I am quite satisfied with it 
all, even if the occasional dead horse takes a beating.  I just 
find it strange that there's such heated debate over something 
that had seemed so settled.  Which, I suppose, might just be an 
indicator that it isn't settled after all, eh?

-- Chris NS
July 18, 2012
Re: ufcs and integer params
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud <philippe.sigaud@gmail.com>:

> > On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
> > > I see from this other discussions that it looks like 2.059 ( or
> > > maybe 2.060) does support something like 3.cm().   Not sure from
> > > the discussion if it would also accept 3.cm as in the xtext/xtend
> > > example.
> 
> Hi Jay,
> 
> I had a little fun with coding a units (SI units) system in D and pushed an
> incomplete version on Github a few weeks ago:
> 
> https://github.com/PhilippeSigaud/Units
> 
> It allows things like:
> 
> auto distance = 100.km;
> auto speed = 120.km/hour;
> 
> auto timeToDestination = distance/speed; // timeToDest is a time (seconds)
> 
> The version on Github is grossly limited (it's just a sketch), but it gives
> an idea of what's possible. My goal is to code a generic unit system
> generator, given user inputs such as a list of units and sub-units.
> 
> cheers,
> 
> Philippe

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));

:D

-- 
Marco
July 18, 2012
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 07:30:10 UTC, Marco Leise wrote:
> Am Sun, 15 Jul 2012 19:17:11 +0200
> schrieb Philippe Sigaud <philippe.sigaud@gmail.com>:
>> […]
>> auto distance = 100.km;
>> auto speed = 120.km/hour;
>> 
>> auto timeToDestination = distance/speed; // timeToDest is a 
>> time (seconds)
>> 
>> The version on Github is grossly limited (it's just a sketch), 
>> but it gives
>> an idea of what's possible. My goal is to code a generic unit 
>> system
>> generator, given user inputs such as a list of units and 
>> sub-units.
>> 
>> […]
>
> 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));

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;
---

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. – but any error messages and symbol names will 
probably look like if the compiler had a seizure.

David
July 18, 2012
Re: ufcs and integer params
On Monday, 16 July 2012 at 23:18:10 UTC, Adam D. Ruppe wrote:
> I'm another who is /vehemently/ against the utter
> idiocy that is the -property switch.

Arguments! Yay!
July 18, 2012
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
> Arguments! Yay!

I've gone over this a dozen times on the group and on
bugzilla, and I'm kinda sick of repeating it.

-property breaks craploads of code. That's a huge negative,
and nobody has even come close to countering that.

"-property will be the standard" is utterly worthless, yet
that's really the only thing I see brought up again.

The other most common thing is "I don't like how writeln = 10
looks". Easy response: then don't write that.

If you're going to break code because someone might write
something you find ugly - note this is different than the 
arguments
people like Crockford make about, say, Javascript's ==, which he 
argues
is a bug 95% of the time you see it, this is just "I don't like 
how
that looks".

But if we're going to let the possibility for subjective ugliness
be justification for BREAKING CODE, I can't stress that enough,
we might as well just nuke the whole language.



BTW, a common fallacy I also here is bringing up the edge cases
like returning a delegate in a property. Two points:

1) That has *nothing* to do with syntax. The @property decoration
takes care of that, regardless of syntax. Why do we have to
break a common case to fix an edge case.... especially when
we /can/ have our cake and eat it too?

2) -property doesn't even get that right anyway. Not kidding,
try it. -property might as well be renamed -break-my-code-and-
give-me-ABSOLUTELY-NOTHING-in-return.

Why, why would we ever consent to having that standard?
July 18, 2012
Re: ufcs and integer params
On Wednesday, 18 July 2012 at 12:30:46 UTC, Adam D. Ruppe wrote:
> 2) -property doesn't even get that right anyway. Not kidding,
> try it. -property might as well be renamed -break-my-code-and-
> give-me-ABSOLUTELY-NOTHING-in-return.
>
> Why, why would we ever consent to having that standard?

I actually tend to agree with this part – I see -property more 
like an experiment help determining the behavior we want to make 
the default with real-world testing. We should definitely try to 
fix/improve the implementation of -property before we consider to 
make it the default. But without it, the discussion might have 
never gotten to the point where we are now, so I still consider 
it a success.

David
July 19, 2012
Re: ufcs and integer params
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote:
> On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
>> Arguments! Yay!
> 
> I've gone over this a dozen times on the group and on
> bugzilla, and I'm kinda sick of repeating it.
> 
> -property breaks craploads of code. That's a huge negative,
> and nobody has even come close to countering that.
> 
> "-property will be the standard" is utterly worthless, yet
> that's really the only thing I see brought up again.

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_.  If someone has @property int foo() and @property void foo(int) as members of a class
and call sites add (), then yanking those back to just int foo; will fail, badly.  So that must be explicitly disallowed.

THAT is the argument for enforcing the lack of parens after properties, imho.  The other bits about non-@property
functions is significantly less important as far as I'm concerned.

My 2 cents,
Brad
1 2 3 4
Top | Discussion index | About this forum | D home