Michel Fortin wrote:
On 2009-08-01 00:04:01 -0400, Benji Smith said:
But XML documents aren't really lists. They're trees.
Do ranges provide an abstraction for working with trees (other than
the obvious flattening algorithms, like breadth-first or depth-first
traversal)?
Well, it depends
Benji Smith wrote:
Andrei Alexandrescu wrote:
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
Bill Baxter wrote:
On Fri, Jul 31, 2009 at 10:09 PM, Andrei
Alexandrescu wrote:
Benji Smith wrote:
So the clusterfuck of unenforceable and useless conventions is already
here. Here's my suggestions: if you think putting parentheses on a no-arg
function is stupid, then it should be a syntax erro
On Sat, Aug 1, 2009 at 11:27 PM, Ellery
Newcomer wrote:
> They aren't. Decorators are deep crazy magic. As I recall,
>
> @mydecorator
> def myfunc(argsnjunk):
> pass
>
> transforms all calls to myfunc to a call to a function you defined
> somewhere named mydecorator, which takes a function and i
Andrei Alexandrescu wrote:
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, th
On Sat, Aug 01, 2009 at 11:49:04PM -0400, Benji Smith wrote:
> >http://igsoft.net/dpolls/poll/results.php?pollid=1
> >http://igsoft.net/dpolls/poll/results.php?pollid=2
> >
> >
> >Andrei
>
> If I'm not mistaken, each of those polls shows a two-to-one preference
> for getting rid of omissable pare
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J
wrote:
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of proper
On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu
wrote:
Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay
the price of
Ary Borenszweig wrote:
> Leandro Lucarella escribió:
>> Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
>>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>>
>> Please, try to post at least the abstract of the DIP with the link, so
>> people can easily know what is it ab
Leandro Lucarella escribió:
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Please, try to post at least the abstract of the DIP with the link, so
people can easily know what is it about =)
And when writing a DIP, try
Chad J schrieb:
aarti_pl wrote:
Ary Borenszweig pisze:
That's because we can't see who is voting and if anyone is cheating.
Trivial cheating is rather not possible - there is only one voice per IP.
BR
Marcin Kuszczak
(aarti_pl)
Interesting. I can't tell because it seems like I can still su
On 2009-08-01 17:38:46 -0400, Jarrett Billingsley
said:
On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin wrote:
3. There is no naming ambiguity.
A set/get prefix removes pretty much all ambiguity too.
I mean, the current syntax is "T transform()" and you can't know if
transform is a noun or
On 2009-08-01 20:15:41 -0400, Sergey Gromov said:
Here's a nice document about directory layout in UNIX-like OSes:
http://www.pathname.com/fhs/pub/fhs-2.3.html
I think MacOS should follow this layout at least in part. In particular
/usr/local/ is used for locally installed packages which oth
Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
defi
Sat, 1 Aug 2009 07:55:08 -0400, Michel Fortin wrote:
> On 2009-08-01 04:41:38 -0400, Anders F Björklund said:
>
>> Jacob Carlborg wrote:
>>
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? [...]
>>> I looked at a gdc installer and look
Leandro Lucarella, el 1 de agosto a las 20:28 me escribiste:
> Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
> > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>
> Please, try to post at least the abstract of the DIP with the link, so
> people can easily know what is
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
I really think that D should support some kind of annotations. I think
it's a good idea to add them in stages. I could add that in the first
stage, old-style attributes/what
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
> To clarify: if there was any extra checking by the compiler, any
> guarantee that the feature would provide at all, I'd be glad to pay the
> price of thinking more when putting together a design. But you want to
> define a language f
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Please, try to post at least the abstract of the DIP with the link, so
people can easily know what is it about =)
And when writing a DIP, try to make the abstract a little
On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
wrote:
Robert Jacques wrote:
I like them too (a lot). I find they increase the clarity of my code
(particularly function chaining).
I think that when you find you need to use function-chaining, the
functions
(except possibly the
Robert Fraser wrote:
> Ary Borenszweig wrote:
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>
> I think annotations are a good idea, but turning keywords already in the
> language into annotations seems kinda pointless & would kill backwards
> compatibility. In C#/Java some thi
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
I think annotations are a good idea, but turning keywords already in the
language into annotations seems kinda pointless & would kill backwards
compatibility. In C#/Java some things are modifiers while other
Tim Matthews wrote:
On Sat, 01 Aug 2009 16:29:28 -0300
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Are pragmas not already here for this?
Nope, they're for compiler-specific extensions
On Sat, 01 Aug 2009 15:28:36 -0400
Chad J wrote:
There are probably others who only check the
> newsgroup every few days. Please give it some time.
I would check the ng more often if it could upgrade it's server /
bandwidth or wherever the bottle neck is.
On Sat, 01 Aug 2009 16:29:28 -0300
Ary Borenszweig wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Are pragmas not already here for this?
On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin wrote:
>> 3. There is no naming ambiguity.
>
> A set/get prefix removes pretty much all ambiguity too.
>
> I mean, the current syntax is "T transform()" and you can't know if
> transform is a noun or a verb. With my prefix it's "T getTransform()" which
"Adam D. Ruppe" wrote in message
news:mailman.258.1249155638.14071.digitalmar...@puremagic.com...
> On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>
> What's the difference between this and a keyword? It seems to
"Andrei Alexandrescu" wrote in message
news:h51q1b$lh...@digitalmars.com...
> bearophile wrote:
>> Andrei Alexandrescu:
>>> Thanks. So it looks like get_property() and set_property() could fly.
>>> How does that sound?
>>
>> Not too much good. Among the simpler solutions there's the 'property'
Ary Borenszweig wrote:
Andrei Alexandrescu escribió:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could
fly. How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in r
Jarrett Billingsley wrote:
> On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig wrote:
>> auto a = x; // OK
>> auto a = x(); // Wrong
>> x = 2; // OK
>> x(2); // Wrong
>
> And furthermore, I mentioned that &obj.foo would always get the
> address of the member 'foo' from 'obj', even if 'foo' was a pro
aarti_pl escribió:
bearophile pisze:
aarti_pl:
What you mean saying "attributes"?<
See for example:
http://en.wikipedia.org/wiki/Java_annotation
It's not an esoteric thing, It's a way to add some extra semantics to
a program.
In a low-level language like D there are other possible purposes
On 2009-08-01 11:56:23 -0400, Jarrett Billingsley
said:
It's been mentioned before, and I'll mention it again: a simple
'property' attribute that can be applied to any function. No new
syntax, no get/set/value 'magic' keywords, just 'property.' Applying
it to a function makes the compiler en
Andrei Alexandrescu escribió:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could fly.
How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in reducing code (it makes c
Robert Jacques wrote:
> I like them too (a lot). I find they increase the clarity of my code
> (particularly function chaining).
I think that when you find you need to use function-chaining, the functions
(except possibly the rightmost) are often meant to be properties/fields.
That's why they wou
bearophile pisze:
aarti_pl:
What you mean saying "attributes"?<
See for example:
http://en.wikipedia.org/wiki/Java_annotation
It's not an esoteric thing, It's a way to add some extra semantics to a program.
In a low-level language like D there are other possible purposes for
annotations/attr
On Sat, 01 Aug 2009 13:05:26 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J
wrote:
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- Th
Adam D. Ruppe escribió:
On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
What's the difference between this and a keyword? It seems to be a keyword
with a different name.
A keyword means changing the lexer, the pa
aarti_pl:
> What you mean saying "attributes"?<
See for example:
http://en.wikipedia.org/wiki/Java_annotation
It's not an esoteric thing, It's a way to add some extra semantics to a program.
In a low-level language like D there are other possible purposes for
annotations/attributes (that aren't
Ary Borenszweig pisze:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Nice! This proposal seems to be really better (more general and
extensible) than any property proposal before.
BR
Marcin Kuszczak
(aarti_pl)
On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
What's the difference between this and a keyword? It seems to be a keyword
with a different name.
For this annotation thing to be really useful, I'd think it should be
Ali Cehreli wrote:
If the default behavior for dout.writefln is to print bool values as the "true" and
"false" strings, then the opposite should be available and arguably be the default:
// "true" and "false" should be acceptable inputs:
bool b;
din.readf(&b);
Am I wrong?
Thanks,
Ali
P
Chad J pisze:
aarti_pl wrote:
I don't think that 23 voters can be representative for D community. If
you have clear opinion about how properties should work in D, then you
can express your opinion. Don't loose your chance :-)
The poll has been up for a bit more than 5 hours now, and 34 people
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Ary Borenszweig escribió:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Ouch. I meant: DIP6: Annotations.
aarti_pl wrote:
>
> I don't think that 23 voters can be representative for D community. If
> you have clear opinion about how properties should work in D, then you
> can express your opinion. Don't loose your chance :-)
>
The poll has been up for a bit more than 5 hours now, and 34 people have
v
aarti_pl wrote:
> Ary Borenszweig pisze:
>>
>> That's because we can't see who is voting and if anyone is cheating.
>
> Trivial cheating is rather not possible - there is only one voice per IP.
>
> BR
> Marcin Kuszczak
> (aarti_pl)
Interesting. I can't tell because it seems like I can still sub
Jarrett Billingsley wrote:
On Sat, Aug 1, 2009 at 1:38 PM, Andrei
Alexandrescu wrote:
Of course they're overridable. They are *functions*.
Then why are you calling them properties? :o)
Stop deliberately misunderstanding me.
Yeah, sorry. Low blow. I shouldn't have sent out that crap.
Andr
bearophile pisze:
> I agree, attributes (or something like that) are a better solution
to this (and other) problem.
What you mean saying "attributes"? Probably I missed some posts...
BR
Marcin Kuszczak
(aarti_pl)
Ary Borenszweig pisze:
Andrei Alexandrescu escribió:
Leandro Lucarella wrote:
aarti_pl, el 1 de agosto a las 16:44 me escribiste:
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added
additional pool about omissible parenthesis feature.
Here is the link:
h
Andrei Alexandrescu:
> We can't throw keywords at problems like they're getting out of style.
> I've noticed that here every little problem gets solved by a little
> keyword. If not, some arcane new syntax.
I agree, attributes (or something like that) are a better solution to this (and
other) p
Andrei Alexandrescu escribió:
Leandro Lucarella wrote:
aarti_pl, el 1 de agosto a las 16:44 me escribiste:
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added
additional pool about omissible parenthesis feature.
Here is the link:
http://www.igsoft.net/dpo
On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig wrote:
> Rainer Deyke escribió:
>>
>> Ary Borenszweig wrote:
>>>
>>> The "property" just signals that the function is a property. But it's
>>> still a function and all of the previous rules that existed are still
>>> valid.
>>
>> My problem with the '
Rainer Deyke escribió:
Ary Borenszweig wrote:
The "property" just signals that the function is a property. But it's
still a function and all of the previous rules that existed are still
valid.
My problem with the 'property' syntax:
Possibility 1: the property still acts like a function, so yo
Ary Borenszweig wrote:
> The "property" just signals that the function is a property. But it's
> still a function and all of the previous rules that existed are still
> valid.
My problem with the 'property' syntax:
Possibility 1: the property still acts like a function, so you can still
do 'x.a()
On Sat, Aug 1, 2009 at 1:38 PM, Andrei
Alexandrescu wrote:
>> Of course they're overridable. They are *functions*.
>
> Then why are you calling them properties? :o)
Stop deliberately misunderstanding me.
>> So let me get this straight: the property attribute would be better
>> technically, but
Andrei Alexandrescu wrote:
> It is ridiculous, particularly in light of the fact that no poll shows
> the landslide prevalence of "everybody".
Not everyone may agree, or understand. But if you look at it objectively,
D's 'properties' cause inconsistencies, ambiguities and limitations. I'm
not lis
Hello!
It is reminder about ongoing voting about D properties proposals. You
can express your opinion.
Current results are as follows:
* 23 voters
* D properties pool:
- 60,87% of people are for introducing new syntax for properties
- 39,13% are for fixing existing problems with current synt
Jarrett Billingsley wrote:
"Andrei Alexandrescu" wrote in message
news:h51rnq$o2...@digitalmars.com...
Jarrett Billingsley wrote:
I'll ask again: do you have any *technical* issues with the 'property'
attribute suggestion?
My main technical issue is throwing a keyword at a very minor issue.
Leandro Lucarella wrote:
aarti_pl, el 1 de agosto a las 16:44 me escribiste:
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added additional pool
about omissible parenthesis feature.
Here is the link:
http://www.igsoft.net/dpolls/index.php
Let's vote and pl
Denis Koroskin wrote:
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J
wrote:
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of properties, but with a list of lim
On 2009-08-01 13:05:26 -0400, "Denis Koroskin" <2kor...@gmail.com> said:
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J
wrote:
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allo
On 2009-08-01 11:31:17 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss,
aarti_pl, el 1 de agosto a las 16:44 me escribiste:
> Ok. Let's do some voting.
>
> I extended pool with latest syntax suggestion. I also added additional pool
> about omissible parenthesis feature.
>
> Here is the link:
>
> http://www.igsoft.net/dpolls/index.php
>
> Let's vote and please do
Jesse Phillips, el 31 de julio a las 15:11 me escribiste:
> It seem no one is confident in their poll writing skills, so I'll take stab
> at it.
>
> This poll is related to D not providing "true" properties. Details and
> discussion can be found in DIP4:
> http://prowiki.org/wiki4d/wiki.cgi?Lan
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J
wrote:
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of properties, but with a list of limitations
and gotchas.
Omissible Parentheses
Could someone remind me why we don't remove these?
So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of properties, but with a list of limitations
and gotchas.
This is not intended to be a deep discussion. I'm writ
"Andrei Alexandrescu" wrote in message
news:h51rnq$o2...@digitalmars.com...
> Jarrett Billingsley wrote:
>> I'll ask again: do you have any *technical* issues with the 'property'
>> attribute suggestion?
>
> My main technical issue is throwing a keyword at a very minor issue.
Yeah, it is pretty
Andrei Alexandrescu escribió:
Jarrett Billingsley wrote:
On Sat, Aug 1, 2009 at 12:21 PM, Andrei
Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could
fly. How
does that sound?
Not too much good. Among the simpler solutio
Ary Borenszweig wrote:
Andrei Alexandrescu escribió:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could
fly. How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in r
Jarrett Billingsley wrote:
On Sat, Aug 1, 2009 at 12:21 PM, Andrei
Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could fly. How
does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attrib
aarti_pl wrote:
> [2],[3],[4] Choosing one of possible options will give you answer what
> is preferred. Also introducing new syntax without removing ommitable
> parenthesis feature doesn't make much sense, as it cause than there is
> no real difference between function and property.
Just wanted t
On Sat, Aug 1, 2009 at 12:21 PM, Andrei
Alexandrescu wrote:
> bearophile wrote:
>>
>> Andrei Alexandrescu:
>>>
>>> Thanks. So it looks like get_property() and set_property() could fly. How
>>> does that sound?
>>
>> Not too much good. Among the simpler solutions there's the 'property'
>> attribute,
Andrei Alexandrescu escribió:
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could fly.
How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in reducing code (it makes c
On Fri, 31 Jul 2009 23:11:41 +0400, Jesse Phillips
wrote:
It seem no one is confident in their poll writing skills, so I'll take
stab at it.
This poll is related to D not providing "true" properties. Details and
discussion can be found in DIP4:
http://prowiki.org/wiki4d/wiki.cgi?Langua
On Sat, Aug 1, 2009 at 12:21 PM, Robert Jacques wrote:
> On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley
> wrote:
>>
>> 1. You can no longer call functions as properties that were never
>> intended to be (writeln = 4; goes away).
>
> *sigh* writeln = 4 doesn't compile and hasn't for a whil
Michel Fortin wrote:
You can use /opt/dmd and /opt/dmd2, if you don't
want to use the regular file hierarchy in hier(7)
In hier(7), it says that "/usr/local" is for "executables, libraries,
etc. not included by the basic operating system", so I guess DMD fits
this quite well.
I normally* u
On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley
wrote:
1. You can no longer call functions as properties that were never
intended to be (writeln = 4; goes away).
*sigh* writeln = 4 doesn't compile and hasn't for a while. It would be
nice if the examples were valid code.
bearophile wrote:
Andrei Alexandrescu:
Thanks. So it looks like get_property() and set_property() could fly.
How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in reducing code (it makes code longer!)
solves most probl
Jarrett Billingsley Wrote:
> On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin
> wrote:
>
> > The best simple solution to that property problem I've seen up to now is to
> > define "getProperty" and "setProperty" and have the compiler automatically
> > check for these functions when it encounters t
Bill Baxter wrote:
On Fri, Jul 31, 2009 at 9:13 AM, Andrei
Alexandrescu wrote:
Sergey Gromov wrote:
Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4lsuo$au...@digitalmars.com...
For me, I get a breath of fresh air whe
On Fri, Jul 31, 2009 at 9:13 AM, Andrei
Alexandrescu wrote:
> Sergey Gromov wrote:
>>
>> Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:
>>
>>> Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4lsuo$au...@digitalmars.com...
>
> For me, I get a breath o
Andrei Alexandrescu:
> Thanks. So it looks like get_property() and set_property() could fly.
> How does that sound?
Not too much good. Among the simpler solutions there's the 'property'
attribute, that while not helping in reducing code (it makes code longer!)
solves most problems, while being
On Fri, Jul 31, 2009 at 10:09 PM, Andrei
Alexandrescu wrote:
> Benji Smith wrote:
>>
>> Andrei Alexandrescu wrote:
>>>
>>> Steven Schveighoffer wrote:
So to sum up, with this feature lack of parentheses would imply no
action, but would not be enforced. However, it would be considere
On Sat, Aug 1, 2009 at 11:54 AM, Andrei
Alexandrescu wrote:
> Jarrett Billingsley wrote:
>>
>> On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
>> Billingsley wrote:
>>>
>>> On Sat, Aug 1, 2009 at 11:31 AM, Andrei
>>> Alexandrescu wrote:
>>>
> To avoid converting to unicode upercase, we could use "get_
On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin wrote:
> The best simple solution to that property problem I've seen up to now is to
> define "getProperty" and "setProperty" and have the compiler automatically
> check for these functions when it encounters the "property" symbol.
>
> Why do I favor
Jarrett Billingsley wrote:
On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
Billingsley wrote:
On Sat, Aug 1, 2009 at 11:31 AM, Andrei
Alexandrescu wrote:
To avoid converting to unicode upercase, we could use "get_thing" and
"set_thing" (nicer than opGet/opSet), although that doesn't really fit with
t
On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
Billingsley wrote:
> On Sat, Aug 1, 2009 at 11:31 AM, Andrei
> Alexandrescu wrote:
>
>>> To avoid converting to unicode upercase, we could use "get_thing" and
>>> "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
>>> the coding stan
On Sat, Aug 1, 2009 at 11:31 AM, Andrei
Alexandrescu wrote:
>> To avoid converting to unicode upercase, we could use "get_thing" and
>> "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
>> the coding standards of D.
>
> Also, again, if you want to define "_thing" you'd ha
Michel Fortin wrote:
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss, no gain: the callee must make the
decision whether the call
Ary Borenszweig:
>But, man, am I so excited to be able to overload my functions and templated
>functions!<
The "support for fast and reliable build tools to the frontend" is a first step
of one of the things people have asked for for a lot of time, so once in a
while Walter listens to people, s
Steven Schveighoffer wrote:
On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu
wrote:
What you need in order to be convincing are better arguments
From the responses from everyone else in this newsgroup, I think you
may be alone in that opinion.
http://poll.pollcode.com/Iy0_result?
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added additional
pool about omissible parenthesis feature.
Here is the link:
http://www.igsoft.net/dpolls/index.php
Let's vote and please do not kill my server ;-)
BR
Marcin Kuszczak
(aarti_pl)
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or withou
Steven Schveighoffer escribió:
On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu
wrote:
What you need in order to be convincing are better arguments
From the responses from everyone else in this newsgroup, I think you
may be alone in that opinion.
I agree. And I also think it's no
On 2009-08-01 00:04:01 -0400, Benji Smith said:
But XML documents aren't really lists. They're trees.
Do ranges provide an abstraction for working with trees (other than the
obvious flattening algorithms, like breadth-first or depth-first
traversal)?
Well, it depends at what level you look
On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu
wrote:
What you need in order to be convincing are better arguments
From the responses from everyone else in this newsgroup, I think you may
be alone in that opinion.
-Steve
On 2009-08-01 04:41:38 -0400, Anders F Björklund said:
Jacob Carlborg wrote:
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? [...]
I looked at a gdc installer and looked where it placed the compiler and
did the same. I don't know where it's
Jeremie Pelletier wrote:
Is there a way to convert a float (or double/real) to an integral number
without changing its binary representation at compile time?
I need to extract the sign, exponent and mantissa yet I cant use bit shifting.
"Error: 'R' is not of integral type, it is a real" is the
Chad J pisze:
There is no mention of how the property implementation actually
generates code. This is important, because the current implementation
is syntax sugar, while my ideal is to have the compiler generate
temporary values to ensure the property always works as expected. It is
possible t
Jacob Carlborg wrote:
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? [...]
I looked at a gdc installer and looked where it placed the compiler and
did the same. I don't know where it's best to place the compiler.
You can use /opt/dmd and /op
1 - 100 of 101 matches
Mail list logo
