I was looking at the xtend example 4 Distances here, and see
that their new generation capability includes ability to do 3.cm
10.mm , and these result in calls to cm(3) and mm(10).
http://blog.efftinge.de/
I see that similar capability was discussed for D previously at
the link below. Ho
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.
http://forum.dlang.org/thread/smoniukqfxerutqrj...@forum.dlang.org
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.
>
> http://forum.dlang.org/thread
> 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
On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
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
On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:
> On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
> > 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
>
On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
> > What is enforced here? Why would it matter if anything is 'enforced'?
>
> If you marked it as a property, then it's supposed to be abstracting a
> variable and should be treated as one, just like if it's a normal function,
> it should b
On 07/15/2012 09:41 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
What is enforced here? Why would it matter if anything is 'enforced'?
If you marked it as a property, then it's supposed to be abstracting a
variable and should be treated as one, just lik
On Sunday, July 15, 2012 22:47:41 Timon Gehr wrote:
> On 07/15/2012 09:41 PM, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
> >>> What is enforced here? Why would it matter if anything is 'enforced'?
> >>
> >> If you marked it as a property, then it's suppos
On 07/15/2012 08:56 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:
On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
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 som
On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
> > The current plan is (and has been for some time)
> > that -property will become the normal behavior,
>
> It is obvious that -property is broken and will not become the normal
> behaviour.
It is obvious that -property needs to be fixed before
On 07/15/2012 11:11 PM, Jonathan M Davis wrote:
There are two levels to enforcement. Neither exist without -property. The
absolutely minimal level is that anything marked with @property must be used
as a property. Without this, you can't swap out a property function for a
variable without break
On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
> > The second level - i.e. strict property enforcement - also requires that
> > non- property functions be called as functions.
>
> Exactly. This part is useless.
And there, we will forever disagree.
- Jonathan M Davis
On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
The second level - i.e. strict property enforcement - also requires that
non- property functions be called as functions.
Exactly. This part is useless.
And there, we will forever disagree.
On 07/15/2012 11:35 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
The current plan is (and has been for some time)
that -property will become the normal behavior,
It is obvious that -property is broken and will not become the normal
behaviour.
It is obvious
On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
> On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
> >>> The second level - i.e. strict property enforcement - also requires that
> >>> non- property functions be called as functions.
> >>
>
On 07/15/2012 11:56 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
The second level - i.e. strict property enforcement - also requires that
non- property functio
On 2012-07-15 21:41, Jonathan M Davis wrote:
And on a purely objective note, if you don't have property enforcement, you
can't turn a property function into a variable, because even though it's
supposed to be used as one, you can't guarantee that everyone's using it that
way, and if they're usin
On 2012-07-15 23:56, Jonathan M Davis wrote:
It's a matter of enforcing the correct syntax, which the compiler does all the
time. It's just that you don't think that the compiler should care in this
particular case, since it hasn't cared in the past.
No, it's a matter of _what_ the correct syn
On 2012-07-16 00:33, Timon Gehr wrote:
This post seems to attempt to distract from the fact that the topic of
the discussion is which syntax is correct.
which the compiler does all the
time. It's just that you don't think that the compiler should care in
this
particular case, since it hasn't c
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" l
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 pro
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.
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
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud :
> > 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 a
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!
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 :
[…]
auto distance = 100.km;
auto speed = 120.km/hour;
auto timeToDestination = distance/speed; // timeToDest is a
time (seconds)
The version on Github is grossly limite
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.
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
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 negati
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 si
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
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,
> 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"
34 matches
Mail list logo