On Tuesday, November 16, 2010 14:45:39 Shin Fujishiro wrote:
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Tuesday 16 November 2010 12:41:29 Shin Fujishiro wrote:
> > > By the way, it feels redundant for me to name every exception class with an ending Exception, especially descriptive ones such as ConvOverflowException.  Couldn't it be ConversionOverflow?
> > 
> > It's clearer and more consistent to have Exception in the name. It makes it nice and obvious that you're dealing with an exception type, and it's not like youe have to type them very often anyway. Also, what would you do for stuff like std.datetime? It has DateTimeException. It's not like you can change it to DateTime. Not only would that be a bad name (since its name is not indicative of an exception or error at all), but there's already a separate DateTime type.
> > 
> > FWIW, all of the exceptions in Java have Exception in their name, and as far as I recall, every exception class that I've used in any other language has had Exception or exception in its name. It makes it nice and clear that you're dealing with an exception type, and while some might be able leave it out - like ConversionOverflow - that leads to inconsistency with all of the exception types which need it in order to make it clear that they're actually an error of some sort.
> > 
> > So, I definitely think that in Phobos and Druntime we should have Exception as the suffix for all Throwables descended from Exception and Error as the suffix for all Throwables descended from Error. It's clear and consistent that way.
> 
> Yeah, I agree that suffixed Exceptions are very clear.  I wrote it because std.concurrency has non-suffixed exceptions such as MessageMismatch, which are still clear thanks to negative terms embedded in their names.

Well, then I'd argue that those exception classes should have their names changed to include Exception, but the negative terms embedded in their names do make them work as they are. It's just inconsistent, and generally-speaking, such inconsistencies in a library should be avoided unless there's a good, overriding reason to have them.

- Jonathan M Davis

On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.

I think that it should be general policy to use deprecated aliases where appropriate to reduce code breakages due to changes in Phobos, but since we're far from API stability, we're going to get breakages, and I really don't think that it's clear outside of anyone really paying attention to D development that Phobos is as unstable and immature as it is. It's definitely improving, but backwards incompatible changes do occur and will continue to occur for at least a little while regardless of the state of the compiler (e.g. std.file.lastModified() will presumably changed to return a std.datetime.SysTime was std.datetime has been approved, and you _can't_ make that change in a way that supports a deprecated backwards-compatible solution since it's only the return value that changes).

In any case, I think that your point is a good one that we should try and only break code old code when it makes good sense to do so, and deprecated aliases can be a good way to reduce such breakages. Eventually, we'll likely have to move to a release cycle with major and minor releases where such breakages are only permitted in major releases, but that's a ways off yet I think.

- Jonathan M Davis

Right.  I'm not arguing for insisting on perfect backwards compatibility, even at the source level.  I also don't think binary backwards compatibility is worth any effort at all yet (and it's largely moot since Phobos is mostly templates).  I'm just saying that we don't want to completely ignore the issue anymore.  If you're going to make breaking changes and there's an easy way to mitigate the breakage, then the breakages should be mitigated.  If there's no easy way to mitigate it, then advance notice should be given.  Given that the aliases have been included, I completely support the changes that have been made.

On 11/16/2010 7:29 PM, Jonathan M Davis wrote:
> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
>> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
> I think that it should be general policy to use deprecated aliases where appropriate to reduce code breakages due to changes in Phobos, but since we're far from API stability, we're going to get breakages, and I really don't think that it's clear outside of anyone really paying attention to D development that Phobos is as unstable and immature as it is. It's definitely improving, but backwards incompatible changes do occur and will continue to occur for at least a little while regardless of the state of the compiler (e.g. std.file.lastModified() will presumably changed to return a std.datetime.SysTime was std.datetime has been approved, and you _can't_ make that change in a way that supports a deprecated backwards-compatible solution since it's only the return value that changes).
>
> In any case, I think that your point is a good one that we should try and only break code old code when it makes good sense to do so, and deprecated aliases can be a good way to reduce such breakages. Eventually, we'll likely have to move to a release cycle with major and minor releases where such breakages are only permitted in major releases, but that's a ways off yet I think.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Nov 16, 2010, at 4:03 PM, Jonathan M Davis wrote:

> On Tuesday, November 16, 2010 14:45:39 Shin Fujishiro wrote:
>> 
>> 
>> Yeah, I agree that suffixed Exceptions are very clear.  I wrote it because std.concurrency has non-suffixed exceptions such as MessageMismatch, which are still clear thanks to negative terms embedded in their names.
> 
> Well, then I'd argue that those exception classes should have their names changed to include Exception, but the negative terms embedded in their names do make them work as they are. It's just inconsistent, and generally-speaking, such inconsistencies in a library should be avoided unless there's a good, overriding reason to have them.

 Changing the name would create an inconsistency with TDPL.

On Tuesday, November 16, 2010 16:48:31 Sean Kelly wrote:
> On Nov 16, 2010, at 4:03 PM, Jonathan M Davis wrote:
> > On Tuesday, November 16, 2010 14:45:39 Shin Fujishiro wrote:
> >> Yeah, I agree that suffixed Exceptions are very clear.  I wrote it because std.concurrency has non-suffixed exceptions such as MessageMismatch, which are still clear thanks to negative terms embedded in their names.
> > 
> > Well, then I'd argue that those exception classes should have their names changed to include Exception, but the negative terms embedded in their names do make them work as they are. It's just inconsistent, and generally-speaking, such inconsistencies in a library should be avoided unless there's a good, overriding reason to have them.
> 
>  Changing the name would create an inconsistency with TDPL.

Well, that would be a reason not to do it, though it wouldn't be the first permanent inconsistency with TDPL. Certainly, I think that the general rule should be that the names of exception types should end in Exception and the names of error types should end in Error. That doesn't necessarily mean that we should never do otherwise, but I think that we should have a good reason if we do. A conflict with TDPL would arguably be a good reason, though I think that I'd still want to change it and leave a deprecated alias (albeit one which would probably have to stick around at least until the next version of TDPL comes out). Regardless, I think that the general naming convention should be used unless there is a good reason otherwise.

- Jonathan M Davis

On 11/16/10 4:29 PM, Jonathan M Davis wrote:
> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
>> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
>
> I think that it should be general policy to use deprecated aliases

A related, very important topic, is that the deprecation message should be user-configurable. I'm thinking something like

deprecated("You may want to use ConvException instead.")

There is no way to achieve that with static if, version, etc. The deprecated warning would spring like now - only when the declaration is actually used.


Andrei

On Tuesday 16 November 2010 17:08:15 Andrei Alexandrescu wrote:
> On 11/16/10 4:29 PM, Jonathan M Davis wrote:
> > On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
> >> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
> > 
> > I think that it should be general policy to use deprecated aliases
> 
> A related, very important topic, is that the deprecation message should be user-configurable. I'm thinking something like
> 
> deprecated("You may want to use ConvException instead.")
> 
> There is no way to achieve that with static if, version, etc. The deprecated warning would spring like now - only when the declaration is actually used.

That's the sort of thing that makes me think that deprecated should be an attribute (since, if D attributes ever become anything like Java attributes like I hope they do, they can take argument like that).

Regardless, that would be a definite improvement, especially if we end up with much deprecated in Phobos. I think that up to this point, we've mostly just made changes rather than deprecate things. I think that std.contracts is the only one that I've seen.

- Jonathan M Davis

Le 2010-11-16 ? 20:08, Andrei Alexandrescu a ?crit :

> On 11/16/10 4:29 PM, Jonathan M Davis wrote:
>> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
>>> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
>> 
>> I think that it should be general policy to use deprecated aliases
> 
> A related, very important topic, is that the deprecation message should be user-configurable. I'm thinking something like
> 
> deprecated("You may want to use ConvException instead.")
> 
> There is no way to achieve that with static if, version, etc. The deprecated warning would spring like now - only when the declaration is actually used.

I think that's a good idea, but my proposal would be to take the message from the "Deprecated:" section of the ddoc comment above. Basically, make the nice error message a compiler feature instead of a language feature.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Can't you use a pragma(msg, ... ) for this ?

On 17 nov 2010, at 02:08, Andrei Alexandrescu wrote:

> On 11/16/10 4:29 PM, Jonathan M Davis wrote:
>> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
>>> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
>> 
>> I think that it should be general policy to use deprecated aliases
> 
> A related, very important topic, is that the deprecation message should be user-configurable. I'm thinking something like
> 
> deprecated("You may want to use ConvException instead.")
> 
> There is no way to achieve that with static if, version, etc. The deprecated warning would spring like now - only when the declaration is actually used.
> 
> 
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

You can use a pragma(msg) to mark a whole module, or a template.  But
you need something like deprecated("...") to mark a non-templated
function or type.

-Lars



On Wed, 2010-11-17 at 12:25 +0100, Jacob Carlborg wrote:
> Can't you use a pragma(msg, ... ) for this ?
> 
> On 17 nov 2010, at 02:08, Andrei Alexandrescu wrote:
> 
> > On 11/16/10 4:29 PM, Jonathan M Davis wrote:
> >> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
> >>> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.
> >> 
> >> I think that it should be general policy to use deprecated aliases
> > 
> > A related, very important topic, is that the deprecation message should be user-configurable. I'm thinking something like
> > 
> > deprecated("You may want to use ConvException instead.")
> > 
> > There is no way to achieve that with static if, version, etc. The deprecated warning would spring like now - only when the declaration is actually used.
> > 
> > 
> > Andrei
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
>