On Wed, 06 May 2009 02:36:21 +0400, Christopher Wright
wrote:
I see no use case for having one module in multiple files, though -- the
only benefit would be private access to things defined in other files.
I've never been big on making stuff private, though.
There is a use-case. Imagine y
Georg Wrede wrote:
Sean Kelly wrote:
dsimcha wrote:
Two closely related topics here:
1. It is often nice to be able to create a single object that works
with both
GC and deterministic memory management. The idea is that, if delete
is called
manually, all sub-objects would be freed determin
Frank Benoit escribió:
In Java one can write:
new MyClass().run();
in D this does not compile, parenthesis are needed.
(new MyClass()).run();
But why is the D language designed like that?
I think it's because the (already hated by many, including myself)
ability to invoke a function (or a
Here I have collected few more bits that may be interesting for D
development/design.
---
In C# the "fixed" statement prevents the garbage collector from relocating a
movable variable. The fixed statement is only permitted in an unsafe context:
http://msdn.microsoft.com/en-us/l
On Tue, May 5, 2009 at 8:49 PM, Derek Parnell wrote:
> So presumably if it was changed to behave as Java, to get the current
> functionality one would need to write ...
>
> new (MyClass().run());
Except that currently has no meaning, since you can't return a type
from a function :P
On Wed, 06 May 2009 00:39:12 +0200, Frank Benoit wrote:
> In Java one can write:
>
> new MyClass().run();
>
> in D this does not compile, parenthesis are needed.
>
> (new MyClass()).run();
>
> But why is the D language designed like that?
So presumably if it was changed to behave as Java, to
Robert Fraser schrieb:
> me too... Bugzilla, anyone?
http://d.puremagic.com/issues/show_bug.cgi?id=2945
dsimcha wrote:
1. Method calls don't need to be virtual.
2. An instance of a subclass cannot be converted to a final instance of the
base class.
3. A final instance can be implicitly converted to a non-final instance, but
the opposite would not work.
Using final as an instance attribute like
BCS wrote:
Reply to Frank,
In Java one can write:
new MyClass().run();
in D this does not compile, parenthesis are needed.
(new MyClass()).run();
But why is the D language designed like that?
vote++
me too... Bugzilla, anyone?
"Frank Benoit" wrote in message
news:gtqf6c$8m...@digitalmars.com...
> In Java one can write:
>
> new MyClass().run();
>
> in D this does not compile, parenthesis are needed.
>
> (new MyClass()).run();
>
> But why is the D language designed like that?
I'm torn on this.
On one hand, I'm uncomfor
Reply to Frank,
In Java one can write:
new MyClass().run();
in D this does not compile, parenthesis are needed.
(new MyClass()).run();
But why is the D language designed like that?
vote++
grauzone wrote:
Christopher Wright wrote:
It *is* possible, by use of public imports.
Are you splitting one file into many? Public import the other modules.
Are you merging many files into one? Leave the other files with just a
public import of the merged file.
Nice story. In reality you fa
In Java one can write:
new MyClass().run();
in D this does not compile, parenthesis are needed.
(new MyClass()).run();
But why is the D language designed like that?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Walter Bright wrote:
> dsimcha wrote:
>> == Quote from Walter Bright (newshou...@digitalmars.com)'s article
>>> dsimcha wrote:
A possible
solution is, given a class:
class Foo {
// Actual implementation.
}
fi
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
A possible
solution is, given a class:
class Foo {
// Actual implementation.
}
final class FooFinal : Foo{
// Dummy that just makes Foo final.
}
With dmd:
final class A { }
class B
Reply to dsimcha,
Several people have griped in the past that D class methods are
virtual by default. I've pointed out to them that you can get around
this by making the methods final. However, this is a bit of a blunt
instrument, because some use cases for a single class may call for
polymorp
Reply to Kagamin,
BCS Wrote:
I've posted the code here:
http://smplsite.com/filebox/error.zip
auto r = (rp == Point(-.5,1.5));
writef("---%s\n", r);
assert(r, "++"~rp.toString);
Is this it?
Yes that's the spot that was (is?) generating an error. I'm not so sure anymore
as my system is
Christopher Wright wrote:
Georg Wrede wrote:
Yigal Chripun wrote:
*but*, I do think that splitting one file that got too big over time
or uniting a bunch of small files into one should be possible.
This would be especially good for us. D is mainly developed by
individuals, and there projects
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> dsimcha wrote:
> > A possible
> > solution is, given a class:
> >
> > class Foo {
> > // Actual implementation.
> > }
> >
> > final class FooFinal : Foo{
> > // Dummy that just makes Foo final.
> > }
> With dmd:
>final
dsimcha wrote:
A possible
solution is, given a class:
class Foo {
// Actual implementation.
}
final class FooFinal : Foo{
// Dummy that just makes Foo final.
}
With dmd:
final class A { }
class B : A { }
Compiling:
test.d(2): Error: class test.B cannot inherit from final clas
On Fri, May 1, 2009 at 12:56 AM, Robert Fraser
wrote:
> bearophile wrote:
>>
>> But today most people use languages like Java, Python, C#, that often
>> shorten developing time even more than D1.
>> D1 is almost a system language, so it's not easy to compete with the
>> productivity of application
BCS Wrote:
> I've posted the code here:
>
> http://smplsite.com/filebox/error.zip
>
auto r = (rp == Point(-.5,1.5));
writef("---%s\n", r);
assert(r, "++"~rp.toString);
Is this it?
IMHO, this proposal does not go far enough. THose that worry about performance
also care about object size. If a vtable or monitor are needed, then people
will still avoid classes for performance.
dsimcha Wrote:
> Several people have griped in the past that D class methods are virtual by
> defa
Georg Wrede wrote:
Sean Kelly wrote:
dsimcha wrote:
Two closely related topics here:
1. It is often nice to be able to create a single object that works
with both
GC and deterministic memory management. The idea is that, if delete
is called
manually, all sub-objects would be freed determin
Sean Kelly wrote:
dsimcha wrote:
Two closely related topics here:
1. It is often nice to be able to create a single object that works
with both
GC and deterministic memory management. The idea is that, if delete
is called
manually, all sub-objects would be freed deterministically, but the
Georg Wrede wrote:
Yigal Chripun wrote:
*but*, I do think that splitting one file that got too big over time
or uniting a bunch of small files into one should be possible.
This would be especially good for us. D is mainly developed by
individuals, and there projects tend to grow organically -
Sean Kelly wrote:
dsimcha wrote:
Two closely related topics here:
1. It is often nice to be able to create a single object that works
with both
GC and deterministic memory management. The idea is that, if delete
is called
manually, all sub-objects would be freed deterministically, but the
Yigal Chripun wrote:
*but*, I do think that splitting one file that got too big over time or
uniting a bunch of small files into one should be possible.
This would be especially good for us. D is mainly developed by
individuals, and there projects tend to grow organically -- as opposed
to the
Sean Kelly wrote:
> ...
>
> import core.runtime;
>
> interface Disposable
> {
> void dispose();
> }
>
> bool handler( Object o )
> {
> auto d = cast(Disposable) o;
>
> if( d !is null )
> {
> d.dispose();
> return false;
> }
> return true;
> }
>
> stati
dsimcha:
I can see you are working a lot to try to improve the implementation of the
language. Thank you for this.
> this comes at the price of worse cache performance
> that can cause lookups to take up to twice as long as the current
> implementation for large AAs. On the other hand, building
30 matches
Mail list logo
