On Thu, Mar 22, 2018 at 06:31:21AM +, Petar via Digitalmars-d wrote:
> On Wednesday, 21 March 2018 at 19:44:19 UTC, H. S. Teoh wrote:
> > On Wed, Mar 21, 2018 at 12:35:08PM -0700, H. S. Teoh via Digitalmars-d
> > wrote: [...]
> > > Cool, passing --DRT-covopt="merge:1" did the trick.
> > [...]
>
On Wednesday, 21 March 2018 at 19:44:19 UTC, H. S. Teoh wrote:
On Wed, Mar 21, 2018 at 12:35:08PM -0700, H. S. Teoh via
Digitalmars-d wrote: [...]
Cool, passing --DRT-covopt="merge:1" did the trick.
[...]
Speaking of which, are the --DRT-* options documented
anywhere?? I don't even know where
On Wed, Mar 21, 2018 at 12:35:08PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Cool, passing --DRT-covopt="merge:1" did the trick.
[...]
Speaking of which, are the --DRT-* options documented anywhere?? I
don't even know where to begin to look, besides in the druntime code
itself.
T
--
U
On Wed, Mar 21, 2018 at 05:34:58PM +, Seb via Digitalmars-d wrote:
> On Wednesday, 21 March 2018 at 16:39:48 UTC, H. S. Teoh wrote:
> > Is it possible to get cumulative code coverage using dmd? I.e.,
> > accumulate code coverage stats over a series of runs from an
> >
On Wednesday, 21 March 2018 at 16:39:48 UTC, H. S. Teoh wrote:
Is it possible to get cumulative code coverage using dmd? I.e.,
accumulate code coverage stats over a series of runs from an
external test suite. Currently, it seems that compiling with
-cov will just overwrite the *.lst files
Is it possible to get cumulative code coverage using dmd? I.e.,
accumulate code coverage stats over a series of runs from an external
test suite. Currently, it seems that compiling with -cov will just
overwrite the *.lst files from previous runs. Do I have to merge the
.lst files externally
On Wednesday, 2 April 2014 at 18:14:46 UTC, Steve Teale wrote:
But both of these approaches are clumsy compared to what I
would like to see.
Yeah, I think it would need language support to be worthwhile in
the long run. I think it makes a lot of sense for constructors
that the superclass has
On Wednesday, 2 April 2014 at 14:23:57 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
>
Yes. This is "inner virtual functions" as opposed to "outer
virtual functions" (C++). The successor to Simula, BETA
(http://daimi.au.dk/~beta/), has this. Si
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
What I wanted was functions that were declared in a base class
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something
d was functions that were declared in a base class as
'cumulative', or something similar. They would have been generally like
virtual functions, except that any derived class that wanted to do
something extra - as opposed to something different, would simply
define an 'extend&#x
On Friday, 7 March 2014 at 10:05:56 UTC, John Colvin wrote:
On Friday, 7 March 2014 at 09:43:07 UTC, Steve Teale wrote:
On Friday, 7 March 2014 at 09:04:29 UTC, John Colvin wrote:
How would these plain functions be different from final ones?
You would be able to redefine them in a derived cla
On Friday, 7 March 2014 at 09:43:07 UTC, Steve Teale wrote:
On Friday, 7 March 2014 at 09:04:29 UTC, John Colvin wrote:
How would these plain functions be different from final ones?
You would be able to redefine them in a derived class using
override to tell the compiler that it was intention
On Friday, 7 March 2014 at 09:04:29 UTC, John Colvin wrote:
How would these plain functions be different from final ones?
You would be able to redefine them in a derived class using
override to tell the compiler that it was intentional. Final
would remain as-is - final.
I think Walter made
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
I can get tantalizingly close to what I want using the extra
constructor argument.
In the base class I define a template function:
string initString(T)()
{
return "string sname =
\""
On Friday, 7 March 2014 at 06:18:47 UTC, Steve Teale wrote:
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
class MyBaseClass {
bool addHandlersCalled = false;
bool delegate(int)[] handlers;
/// Subclasses must call this in
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
class MyBaseClass {
bool addHandlersCalled = false;
bool delegate(int)[] handlers;
/// Subclasses must call this in their ctor.
protected void addHandlers(bool delegate(i
On 3/6/2014 11:48 AM, Steve Teale wrote:
I've also noticed from the responses, and from responses to associated
questions, that OOP has become almost a dirty word in the D community.
It's old fashioned and slow. So if you're in that camp, you can stop
reading now.
FWIW, I don't think that's r
s
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler
On Thursday, 27 February 2014 at 21:44:20 UTC, Shammah Chancellor
wrote:
On 2014-02-26 16:05:19 +, Steve Teale said:
Actually, D has the ability to walk the object hierarchy at
compile time, and generate a function call containing all the
super classes's handleCommands. You could also eve
On 2014-02-26 16:05:19 +, Steve Teale said:
On Wednesday, 26 February 2014 at 13:30:15 UTC, Leandro Motta Barros wrote:
Hello,
I'm coming late to the discussion, but I believe that you can use the
following idiom to achieve the same results in a different way:
Yes we went through that, i
On Wednesday, 26 February 2014 at 13:30:15 UTC, Leandro Motta
Barros wrote:
Hello,
I'm coming late to the discussion, but I believe that you can
use the
following idiom to achieve the same results in a different way:
Yes we went through that, if you go back a page you'll find a
post I did t
nd it still pops into my head from
> time to time.
>
> What I wanted was functions that were declared in a base class as
> 'cumulative', or something similar. They would have been generally like
> virtual functions, except that any derived class that wanted to do
> somethi
On Tuesday, 25 February 2014 at 11:04:24 UTC, Steve Teale wrote:
On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote:
I'm writing a little example program that illustrates what I'm
getting at, and I'll post it somewhere when I'm through.
OK, it's at britseyeview.com/cumulative.txt
On 2014-02-25 05:38:15 +, Jesse Phillips said:
When I've had a need for base classes to call super class functions, I
certainly wanted a way to enforce it. I just don't know if it would
just lead to other OOP design problems.
Sounds like a good reason to use unittests to me. The compile
On Tuesday, 25 February 2014 at 03:13:23 UTC, Shammah Chancellor
wrote:
So far as I'm understanding this thread, Steve Teale is asking
for a way to inject code before and after a call to a function
from other places in the program. E.g. Write some function
foo, write some function bar, and s
On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote:
I'm writing a little example program that illustrates what I'm
getting at, and I'll post it somewhere when I'm through.
OK, it's at britseyeview.com/cumulative.txt.
I think enforcement of the call to super.handleCommand() would
On 2014-02-25 11:04:23 +, Steve Teale said:
OK, it's at britseyeview.com/cumulative.txt.
I think enforcement of the call to super.handleCommand() would get most
of the way down the road. More could be done if the compiler inserted
the super call, and maintained an implicit class member eq
On Tuesday, 25 February 2014 at 11:13:44 UTC, Shammah Chancellor
wrote:
On 2014-02-25 05:38:15 +, Jesse Phillips said:
When I've had a need for base classes to call super class
functions, I certainly wanted a way to enforce it. I just
don't know if it would just lead to other OOP design pr
On 2014-02-25 10:23:31 +, Steve Teale said:
On Tuesday, 25 February 2014 at 03:13:23 UTC, Shammah Chancellor wrote:
So far as I'm understanding this thread, Steve Teale is asking for a
way to inject code before and after a call to a function from other
places in the program. E.g. Write
"qznc" writes:
> Sounds a little like the :after mechanism of the Common Lisp Object
> System (CLOS). They also have :before, if your extra code should run
> before the super-call. The third variant is :around, which is like the
> default overwriting in D et. al.
Yes! - and CLOS came from my all
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
extend void foo() // Declared in base class as cumulative
void foo()
{
super.foo(); // Compiler does this for you
// similar to changing a
light bulb ;=)
// the extra stuff
}
When
On 2014-02-25 01:08:47 +, Tofu Ninja said:
On Tuesday, 25 February 2014 at 00:55:55 UTC, Tofu Ninja wrote:
Also, in some cases it is not enough just to ensure that it is called,
some times you will want to make sure that it is called at the
beginning or end of the function. Though this is
On Tuesday, 25 February 2014 at 00:55:55 UTC, Tofu Ninja wrote:
Also, in some cases it is not enough just to ensure that it is
called, some times you will want to make sure that it is called
at the beginning or end of the function. Though this is harder
to get right, not really sure how it woul
On Tuesday, 25 February 2014 at 00:18:47 UTC, Namespace wrote:
Maybe:
extend void foo() { ... }
would force you to use super.foo() and otherwise gives an error?
class Foo {
void foo() {
// ...
}
}
class Bar : Foo {
extend void foo() {
// compiler will
Maybe:
extend void foo() { ... }
would force you to use super.foo() and otherwise gives an error?
class Foo {
void foo() {
// ...
}
}
class Bar : Foo {
extend void foo() {
// compiler will force you (opposed to override) that you
call super.foo() but i
On 2/24/2014 3:41 AM, Steve Teale wrote:
extend void foo() // Declared in base class as cumulative void foo()
{
(cast(BaseClass) this).foo(); // Compiler does this for you
// similar to changing a light bulb ;=)
// the extra stuff
}
I think also
s
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler
On Monday, 24 February 2014 at 08:55:02 UTC, Gary Willoughby
wrote:
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
What I wanted was functions that were declared in a base class
as 'cumulative', or something similar. They would have been
generally like virtual
s
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler
s
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler
s
as 'cumulative', or something similar. They would have been
generally like virtual functions, except that any derived class
that wanted to do something extra - as opposed to something
different, would simply define an 'extend', and just specify
the extra code. The compiler
25 years ago, when I was trying to write some sort of library to
go with Walter's C++ compiler, I had a wish, and it still pops
into my head from time to time.
What I wanted was functions that were declared in a base class as
'cumulative', or something similar. They would have
42 matches
Mail list logo
