Andrei Alexandrescu Wrote:
> If a function throws a class inheriting Error but not Exception (i.e. an
> unrecoverable error), then the postcondition doesn't need to be satisfied.
>
> I just realized that postconditions, however, must be satisfied if the
> function throws an Exception-derived ob
I think I have a solution to some problems that occur in OO design. The
problems occurs when a method can be implemented that provides a great
functionality for a specific class, but which it is not valid for its
subclasses without extra work. The classic examples in C++ would be serialize.
v
On Dec 4, 09 13:16, bearophile wrote:
Walter Bright:
While I like them a lot, it's time for them to go:
1. It's hard to remember which one does what
2. They've failed to catch on
3. No operator overloading for them
4. They are only rarely needed; a special operator is not justified
Before tra
Walter Bright:
> While I like them a lot, it's time for them to go:
>
> 1. It's hard to remember which one does what
> 2. They've failed to catch on
> 3. No operator overloading for them
> 4. They are only rarely needed; a special operator is not justified
Before trashing everything some useful c
Andrei Alexandrescu Wrote:
> Sorry. So a !>= b is indeed semantically equivalent with isnan(a) ||
> isnan(b) || a < b. However, if I read the table at
> http://www.digitalmars.com/d/2.0/expression.html#RelExpression
> correctly, !(a >= b) would throw if either is NaN.
>
But there is a note und
ZY.Zhou wrote:
Andrei Alexandrescu Wrote:
a peephole optimization can detect isnan(a) || a < b and have it
translate into one instruction, same as a !>= b,
I think most people would use !(a>=b) rather than isnan(a) || isnan(b) || a < b
Sorry. So a !>= b is indeed semantically equivalent wit
Andrei Alexandrescu Wrote:
>
> a peephole optimization can detect isnan(a) || a < b and have it
> translate into one instruction, same as a !>= b,
I think most people would use !(a>=b) rather than isnan(a) || isnan(b) || a < b
Michel Fortin wrote:
On 2009-12-03 17:16:11 -0500, Andrei Alexandrescu
said:
I found one more example.
A function that transfers money from one account to another must
provide a postcondition even in the case of failure: no matter what,
upon exit, the sum of the monies in the accounts is p
On 2009-12-03 17:16:11 -0500, Andrei Alexandrescu
said:
I found one more example.
A function that transfers money from one account to another must
provide a postcondition even in the case of failure: no matter what,
upon exit, the sum of the monies in the accounts is preserved. The
transfe
Clay Smith wrote:
Disclaimer: Within a finite amount of time, I wrote this quickly, fully
explaining the finer details would take a lonnng time ;)
Nice disclaimer.
Are you aware of the phrase, variously attributed to Shaw, Russell, and
Pascal: "Please excuse the length of this letter; I do not
Thu, 03 Dec 2009 21:35:14 +, BCS wrote:
> Hello dsimcha,
>
>> == Quote from BCS (n...@anon.com)'s article
>>
>>> Show me ONE thing that can be done using run time meta programming
>>> that can't
>>> be done as well or better with run time, non-dynamic, non-meta and/or
>>> compile
>>> time me
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome of a
function. After having listened to those endless Boeing stories,
please listen to this one :o). Contract Programming covers the
correc
On Thu, 3 Dec 2009, Pelle M?nsson wrote:
> Andrei Alexandrescu wrote:
> > As others have mentioned, you may have different postconditions depending on
> > whether an exception was thrown or not.
> >
> > I think a major failure of exceptions as a language mechanism is that they
> > gave the illusi
Walter Bright wrote:
!<>=
<>
<>=
!<=
!<
!>=
!>
!>=
http://www.digitalmars.com/d/2.0/expression.html#RelExpression
While I like them a lot, it's time for them to go:
1. It's hard to remember which one does what
2. They've failed to catch on
3. No operator overloading for them
4. They are only r
!<>=
<>
<>=
!<=
!<
!>=
!>
!>=
http://www.digitalmars.com/d/2.0/expression.html#RelExpression
While I like them a lot, it's time for them to go:
1. It's hard to remember which one does what
2. They've failed to catch on
3. No operator overloading for them
4. They are only rarely needed; a specia
Hello dsimcha,
== Quote from BCS (n...@anon.com)'s article
Show me ONE thing that can be done using run time meta programming
that can't
be done as well or better with run time, non-dynamic, non-meta and/or
compile
time meta. Unless I'm totally clueless as to what people are talking
about
when
dsimcha wrote:
== Quote from BCS (n...@anon.com)'s article
Show me ONE thing that can be done using run time meta programming that can't
be done as well or better with run time, non-dynamic, non-meta and/or compile
time meta. Unless I'm totally clueless as to what people are talking about
when t
== Quote from BCS (n...@anon.com)'s article
> Show me ONE thing that can be done using run time meta programming that can't
> be done as well or better with run time, non-dynamic, non-meta and/or compile
> time meta. Unless I'm totally clueless as to what people are talking about
> when they say ru
Hello Bill,
On Wed, Dec 2, 2009 at 3:26 PM, BCS wrote:
Hello Sergey,
They can, but I question if it's the best way to do it in those
languages. Generating code and running it at runtime seems to be
pointless. Why have the intermediate step with the code? I have
something I want to do, so I u
Hello retard,
Wed, 02 Dec 2009 21:16:28 +, BCS wrote:
Hello Leandro,
Again *optimization*. How many times should I say that I agree that
D is better than almost every dynamic languages if you need speed?
I'm not arguing on that point. What I'm arguing is that (at least for
me) the prim
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e.
an unrecoverable error), then the postcondition doesn't need to be
satisfied.
I just realized that postconditions, however, must be satisfied if
t
Steven Schveighoffer wrote:
On Thu, 03 Dec 2009 13:47:25 -0500, Andrei Alexandrescu
wrote:
Don wrote:
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
This may sound crazy, but if you just follow the facts that
distinguish
regular error handling from prog
On Thu, 03 Dec 2009 13:47:25 -0500, Andrei Alexandrescu
wrote:
Don wrote:
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
This may sound crazy, but if you just follow the facts that
distinguish
regular error handling from program correctness, you must l
Don wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
TD
Andrei Alexandrescu wrote:
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
TDPL says that
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
TDPL says that in non-release mode, public
Don wrote:
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
This may sound crazy, but if you just follow the facts that distinguish
regular error handling from program correctness, you must live with the
consequences. And the consequence is - a function's post
Don wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome
of a
function. After having listened to those endless Boeing stories,
please listen to this one :o
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
This may sound crazy, but if you just follow the facts that distinguish
regular error handling from program correctness, you must live with the
consequences. And the consequence is - a function's postcondition mu
Andrei Alexandrescu wrote:
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome of a
function. After having listened to those endless Boeing stories,
please listen to this one :o). Contract P
On Wed, Dec 02, 2009 at 11:50:23AM +, retard wrote:
> The case I commented on was about fetching values from a db IIRC.
What happened to me was the value got returned as the incorrect type, stored,
and used later where it threw the exception..
Conceptual code here:
===
def getPermission(use
Denis Koroskin wrote:
On Thu, 03 Dec 2009 06:51:32 +0300, Andrei Alexandrescu
wrote:
If a function throws a class inheriting Error but not Exception (i.e.
an unrecoverable error), then the postcondition doesn't need to be
satisfied.
I just realized that postconditions, however, must be sat
Don wrote:
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
I think it has to. Otherwise,
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
Think Boeing: an exception is a possible a
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e. an
unrecoverable error), then the postcondition doesn't need to be satisfied.
If an 'Error' is truly unrecoverable, then there's no point in treating
it as an exception. Just d
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e.
an unrecoverable error), then the postcondition doesn't need to be
satisfied.
I just realized that postconditions, however, must be satisfied if the
function throws an Except
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
This may sound crazy, but if you just follow the facts that distinguish
regular error handling from program correctness, you must live with the
consequences. And the consequence is - a function's postcondition must
be designed to take into
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Well you must do as you preach. Throwing a non-Error exception does not
absolve a method from preserving the class invariant.
Again: thr
Don wrote:
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e.
an unrecoverable error), then the postcondition doesn't need to be
satisfied.
I just realized that postconditions, however, must be satisfied if the
function throws an Exception-derive
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome of a
function. After having listened to those endless Boeing stories,
please listen to this one :o). Contract Programming covers the
correc
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome of a
function. After having listened to those endless Boeing stories,
please listen to this one :o). Contract Programming covers the
correctness of a program, and exceptions are co
On Thu, 03 Dec 2009 19:31:06 +0300, bearophile
wrote:
Denis Koroskin:
Unless we all insist on introducing it before it's too late!<
I'd like an experimental approach: an lateral branch of DMD2 can be
created with this feature. In about a month of its usage I think we can
understand if
On 2009-12-03 11:06:32 -0500, "Denis Koroskin" <2kor...@gmail.com> said:
Non-nullable references are getting more and more popular. I hope one
day we will convince Walter to introduce this idiom to D, too.
Unfortunately, it is unlikely for D2 to get this feature in its
time-frame (because it
Denis Koroskin:
>Unless we all insist on introducing it before it's too late!<
I'd like an experimental approach: an lateral branch of DMD2 can be created
with this feature. In about a month of its usage I think we can understand if
it's a worth feature or not.
Bye,
bearophile
On Thu, 03 Dec 2009 18:59:11 +0300, bearophile
wrote:
"Non-Nullable References by Default" by Christopher Diggins, on Dr.
Dobb's Code Talk:
http://dobbscodetalk.com/index.php?option=com_myblog&show=Non-Nullable-References-by-Default.html&Itemid=29
Bye,
bearophile
Non-nullable references
"Non-Nullable References by Default" by Christopher Diggins, on Dr. Dobb's Code
Talk:
http://dobbscodetalk.com/index.php?option=com_myblog&show=Non-Nullable-References-by-Default.html&Itemid=29
Bye,
bearophile
Walter Bright Wrote:
> Jesse Phillips wrote:
> > Well, part of the problem is that you can use all of those arguments
> > against D (That includes the complaint about Lisp). Maybe not if you
> > just look at D1 or just D2, and many times the complaints aren't as
> > big an issue as they are made o
On 2009-12-03 01:06:07 -0500, Walter Bright said:
Brad Roberts wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
An exception (not an Error) is an expected and documented outcome of a
function. After having listened to those endless Boeing stories,
please listen to this one :o). Contrac
Jesse Phillips schrieb:
I'm not claiming D is in the wrong in its chosen path. This shows that other
languages deal with similar issues, but is one thing for someone familiar with
a language to not choose it for a project than it is to get someone to look
into a new language.
From time to ti
BCS wrote:
Hello dsimcha,
== Quote from BCS (n...@anon.com)'s article
I don't have a link or anything but I remember hearing about a study
MS did
about finding bugs and what they found is that every reasonably
effective
tool they looked at found the same amount of bugs (ok, within
shouting di
On Thu, 03 Dec 2009 06:51:32 +0300, Andrei Alexandrescu
wrote:
If a function throws a class inheriting Error but not Exception (i.e. an
unrecoverable error), then the postcondition doesn't need to be
satisfied.
I just realized that postconditions, however, must be satisfied if the
func
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
I think it has to. Otherwise, how can the
Brad Roberts wrote:
Walter Bright wrote:
Rory McGuire wrote:
I would think that if a method in a class throws then at least the
class' invariant should be run? does it?
No.
Do you consider that broken or correct?
Not sure.
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e. an
unrecoverable error), then the postcondition doesn't need to be satisfied.
I just realized that postconditions, however, must be satisfied if the
function throws an Exception-derived object. The
Andrei Alexandrescu wrote:
> If a function throws a class inheriting Error but not Exception (i.e. an
> unrecoverable error), then the postcondition doesn't need to be satisfied.
If an 'Error' is truly unrecoverable, then there's no point in treating
it as an exception. Just dump the core and get
Andrei Alexandrescu wrote:
If a function throws a class inheriting Error but not Exception (i.e. an
unrecoverable error), then the postcondition doesn't need to be satisfied.
I just realized that postconditions, however, must be satisfied if the
function throws an Exception-derived object. The
torhu wrote:
On 03.12.2009 1:13, Jesse Phillips wrote:
This has come up as one issue for adoption to D. D2.x is on its way,
unstable, and D1.x is getting the ax. While Walter has said that the
compiler will continue to get support, no one in the community knows
what the library support will be
Andrei Alexandrescu wrote:
> This may sound crazy, but if you just follow the facts that distinguish
> regular error handling from program correctness, you must live with the
> consequences. And the consequence is - a function's postcondition must
> be designed to take into account exceptional pat
Walter Bright wrote:
> Rory McGuire wrote:
>> I would think that if a method in a class throws then at least the
>> class' invariant should be run? does it?
>
> No.
Do you consider that broken or correct?
59 matches
Mail list logo
