Steven Schveighoffer Wrote:
If you have to use .net arrays instead of D arrays in order to use
D.net, that would be a deal-killer for me.
Of course, .net arrays will be used, it's .net after all.
Bill Baxter wrote:
On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley
jarrett.billings...@gmail.com wrote:
On Mon, Dec 22, 2008 at 8:59 AM, bearophile bearophileh...@lycos.com wrote:
Jarrett Billingsley:
I suppose you mean for normal arrays. How about reverse as well?
I'd like to see
Lutger wrote:
I noticed many developers really adore properties, perhaps it's worth some
attention to rethink how this is handled in D. It is used everywhere in .NET.
This is exactly where I'm coming from. I used to use C# properties a
lot. They are super effective.
On Tue, Dec 23, 2008 at 6:08 PM, KennyTM~ kenn...@gmail.com wrote:
Bill Baxter wrote:
On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley
jarrett.billings...@gmail.com wrote:
On Mon, Dec 22, 2008 at 8:59 AM, bearophile bearophileh...@lycos.com
wrote:
Jarrett Billingsley:
I suppose you
KennyTM~:
But but but... there's std.complex already.
You are right, I am sorry.
bearophile
Mikola Lysenko:
Conclusion: Complex builtins were an interesting idea, but in practice
they're rarely used. Phasing them into a library template would eliminate a
bunch of redundant code, simplify the language in a meaningful way and
improve flexibility. Win all around.
It seems that
Chad J Wrote:
This is exactly where I'm coming from. I used to use C# properties a
lot. They are super effective.
In C# you can use for example:
class TimePeriod {
private double seconds;
public double Hours {
get { return seconds / 3600; }
set { seconds = value *
bearophile wrote:
Chad J Wrote:
This is exactly where I'm coming from. I used to use C# properties a
lot. They are super effective.
In C# you can use for example:
class TimePeriod {
private double seconds;
public double Hours {
get { return seconds / 3600; }
set {
This was already discussed in the past, but I think it doesn't hurt rehashing
it a little, when there's an opinion of a famous computer scientist and
programmer like
Tony Hoare: Null References: The Billion Dollar Mistake presentation:
I call it my billion-dollar mistake. It was the invention
From my point of view , with the incapable of DMD header generating the
one at a time compiling option can never boost up the compiling speed. So
with the give situation why still rebuild make compiling oneatatime as
default? It's even annoying of the current compulsory behavior. It tries
Bill Baxter wrote:
On Tue, Dec 23, 2008 at 11:30 AM, Jerry Quinn jlqu...@optonline.net wrote:
Walter Bright Wrote:
I've been working on improving the optimizer to take advantage of
immutability and purity.
http://www.reddit.com/r/reddit.com/comments/7l5x4/optimizing_immutable_and_purity/
On 2008-12-23 11:47:56 +0100, Chad J gamerc...@__spam.is.bad__gmail.com said:
Lutger wrote:
I noticed many developers really adore properties, perhaps it's worth
some attention to rethink how this is handled in D. It is used
everywhere in .NET.
This is exactly where I'm coming from. I used
Daniel de Kok wrote:
With no intention to flame, but I never quite understood why people are
so keen on properties over getter/setter member functions. What
advantage does it have over obscuring direct member access and indirect
member access?
This 'obscuring' is exactly what makes
在 Tue, 23 Dec 2008 22:06:17 +0800，davidl dav...@126.com 写道:
From my point of view , with the incapable of DMD header generating the
one at a time compiling option can never boost up the compiling speed.
So with the give situation why still rebuild make compiling oneatatime
as default?
Daniel de Kok m...@nowhere.nospam wrote in message
news:gir3fq$1qj...@digitalmars.com...
On 2008-12-23 11:47:56 +0100, Chad J gamerc...@__spam.is.bad__gmail.com
said:
Lutger wrote:
I noticed many developers really adore properties, perhaps it's worth
some attention to rethink how this is
On 2008-12-23 20:09:56 +0100, Nick Sabalausky a...@a.a said:
Daniel de Kok m...@nowhere.nospam wrote in message
news:gir3fq$1qj...@digitalmars.com...
I think that the D approach is good enough, since it does not add
complexity for library designers.
Library designers are exactly the people
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Tue, Dec 23, 2008 at 11:30 AM, Jerry Quinn jlqu...@optonline.net
wrote:
This was an interesting read. It would be nice to see a discussion
of how const is going to fit in in terms of optimization potential,
since you can always cast it away.
aarti_pl Wrote:
Andrei Alexandrescu pisze:
We're trying to make that work. D is due for an operator overhaul.
Andrei
Is there any chance that we get possibility to overload raw operators,
like in C++? I think that they may coexist with currently defined
operator overloads with
Daniel de Kok:
It comes at virtually no extra cost,
and there is a good chance that simple setters will require some
validation or locking in the future anyway.
It comes at no cost in Java, for example on the HotSpot JVM, and probably on
dotnet too. But probably the current D compilers
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive, compiletime based and typesafe
and even far more be able than what you can do with operator
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive, compiletime based and typesafe
and even far more be able than what
Daniel de Kok m...@nowhere.nospam wrote in message
news:girh4b$2gs...@digitalmars.com...
On 2008-12-23 20:09:56 +0100, Nick Sabalausky a...@a.a said:
Daniel de Kok m...@nowhere.nospam wrote in message
news:gir3fq$1qj...@digitalmars.com...
I think that the D approach is good enough, since it
dennis luehring pisze:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive, compiletime based and typesafe
and even far more be able than what you
Ary Borenszweig pisze:
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive, compiletime based and typesafe
and even far
Autocompletion and syntax coloring.
ok one reason - but is the sql syntax not crippled enough using
operators - better if colored/autocompleted?
what does coloring help here
select
x,
y = (select u from b where ... ),
from select( xyz from abc )
left join
in the special case of inner
Denis Koroskin pisze:
Slightly off-topic.
How would you implement, say, LIKE condition? Similar to the following, perhaps:
Query query = Select(a).Where(id.Like(%substring%));
Well, probably:
...Like(id, substring)...
In this case I prefer this kind of syntax more than OO kind of syntax :-)
On Wed, 24 Dec 2008 00:01:20 +0300, Ary Borenszweig a...@esperanto.org.ar
wrote:
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be
dennis luehring pisze:
aarti_pl schrieb:
Ary Borenszweig pisze:
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive,
Ary Borenszweig escribió:
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive, compiletime based and typesafe
and even
Denis Koroskin wrote:
Slightly off-topic.
How would you implement, say, LIKE condition? Similar to the following, perhaps:
Query query = Select(a).Where(id.Like(%substring%));
You could implement == the same way:
Query query = Select(a).Where(id.EqualsTo(5));
downs way:
auto query1 =
Daniel de Kok m...@nowhere.nospam wrote in message
news:girn6u$2sn...@digitalmars.com...
On 2008-12-23 22:10:53 +0100, Nick Sabalausky a...@a.a said:
It's far more than a mere presumption:
class Foo{
public int x;
}
// vs
class Foo{
private int _x;
public int getX() {
Daniel de Kok wrote:
On 2008-12-23 22:10:53 +0100, Nick Sabalausky a...@a.a said:
It's far more than a mere presumption:
class Foo{
public int x;
}
// vs
class Foo{
private int _x;
public int getX() {
return x;
}
public void setX(int x) {
_x = x;
}
}
It
Walter Bright wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Tue, Dec 23, 2008 at 11:30 AM, Jerry Quinn jlqu...@optonline.net
wrote:
This was an interesting read. It would be nice to see a discussion
of how const is going to fit in in terms of optimization potential,
since you can
Nick Sabalausky wrote:
Donnos...@nospam.com wrote in message
news:gio27n$2o0...@digitalmars.com...
bearophile wrote:
There are some things I'd like to see added to the D language, but what
things can be removed from it?
* C-style declarations
I certainly wouldn't mind seeing these go. But
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Tue, Dec 23, 2008 at 11:30 AM, Jerry Quinn
jlqu...@optonline.net wrote:
This was an interesting read. It would be nice to see a discussion
of how const is going to fit in in terms of
It is possible and it works :-)
But with operator overloading it is so much more readable, than without it.
Creating queries at runtime is quite common:
age = 20;
string query = Select name, surname FROM persons WHERE age = +
to!(string)(age);
that is not object + operator based - your
Weed Wrote:
The problem is not in use templates.
Templates are implementing some of the functionality of 2 types of
structures matrices (normal and dynamic). But the structures do not
inherit, then to add functionality matrix to other entities ( pixel,
image etc) sites will have their
Kagamin пишет:
Weed Wrote:
The problem is not in use templates.
Templates are implementing some of the functionality of 2 types of
structures matrices (normal and dynamic). But the structures do not
inherit, then to add functionality matrix to other entities ( pixel,
image etc) sites will
On Tue, 23 Dec 2008 00:07:08 -0800, Janderson wrote:
Moritz Warning wrote:
On Tue, 16 Dec 2008 19:54:11 +, BCS wrote:
Reply to Moritz,
Hi,
I have problems to convert a char[4] to an uint at compile time. All
variations (I've tried) of using an enum crashes dmd:
union pp { char[4]
I am using D1, while you probably use D2. I have compiled the following code
with -O -release -inline, with the last DMD 1.x:
import std.stdio: writefln;
void foo(string s1, string s2) {
string con = s1 ~ s2;
writefln(con);
}
void main() {
while(true) {
string t1 = Do;
40 matches
Mail list logo
