Sean Kelly wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Andrei Alexandrescu wrote:
I agree. I'm having the same problem: I put a contract in there, I know
it's as good as assert. So I can't do e.g. input validation because in
most functions input must always be
On Wed, 04 Mar 2009 08:12:48 -0800, Sean Kelly wrote:
So I guess the real question is whether a function is expected to
validate its parameters. I'd argue that it isn't, but then I'm from a
C/C++ background. For me, validation is a debugging tool, or at least
an optional feature for
Sean Kelly wrote:
Why should contracts be limited to parameter checking of internally used
functions only? If I write a function and document parameter constraints
then I certainly expect those constraints to be followed regardless of
whether I'm calling the function or someone else is calling
On 2009-03-02 23:27:49 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Georg Wrede wrote:
[snip]
Well I guess what I'll do is take the path of least resistance -
nothing. Looks like locales are rather unpopular...
Sad.
Seriously, I think if D could have locales as a
On Mon, 02 Mar 2009 01:37:55 -0800, Walter Bright
newshou...@digitalmars.com wrote:
Georg Wrede wrote:
We've had Walter make nice features to D that were laborious to create,
only to see nobody use them. It's happened, ask him.
Sure. Often the only way to see if a feature is useful is to
Walter Bright wrote:
Georg Wrede wrote:
We've had Walter make nice features to D that were laborious to
create, only to see nobody use them. It's happened, ask him.
Sure. Often the only way to see if a feature is useful is to actually
implement it and see what happens. Some features have
Daniel Keep:
So I put contracts on everything. Fantastic. I do a release compile,
and all that safety disappears. So only the debug build has contracts
enabled. But it's the release build, if it crashes, that I need help
diagnosing.
A simple solution is to not use -release for the final
bearophile wrote:
Daniel Keep:
So I put contracts on everything. Fantastic. I do a release compile,
and all that safety disappears. So only the debug build has contracts
enabled. But it's the release build, if it crashes, that I need help
diagnosing.
A simple solution is to not use
Tue, 03 Mar 2009 07:05:51 -0800, Andrei Alexandrescu wrote:
bearophile wrote:
Daniel Keep:
So I put contracts on everything. Fantastic. I do a release compile,
and all that safety disappears. So only the debug build has contracts
enabled. But it's the release build, if it crashes, that I
Michel Fortin wrote:
On 2009-03-02 14:58:26 -0500, Walter Bright newshou...@digitalmars.com
said:
It's a silly thing, but I love the little google widget you can add to
a web page to automatically translate the pages. All the D site pages
have it in the left column.
It's not a silly thing,
Andrei Alexandrescu wrote:
I agree. I'm having the same problem: I put a contract in there, I know
it's as good as assert. So I can't do e.g. input validation because in
most functions input must always be validated. I also know that
contracts are doing the wrong thing with inheritance and
On Tue, 03 Mar 2009 11:00:36 -0800, Walter Bright
newshou...@digitalmars.com wrote:
Andrei Alexandrescu wrote:
I agree. I'm having the same problem: I put a contract in there, I know
it's as good as assert. So I can't do e.g. input validation because in
most functions input must always be
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Andrei Alexandrescu wrote:
I agree. I'm having the same problem: I put a contract in there, I know
it's as good as assert. So I can't do e.g. input validation because in
most functions input must always be validated. I also
On Tue, 03 Mar 2009 11:00:36 -0800, Walter Bright wrote:
Contracts are not for input validation!
Hear! Hear! This is exactly correct.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Georg Wrede wrote:
Let's split this into two separate issues, the console and the GUI.
The GUI is aware of your preferences.
You don't use writefln with the GUI.
You use the GUI API for any I/O, right?
There's a third faction: graphical apps that don't use the underlying
GUI API. Most
Georg Wrede wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they
find fit, and also pass around
Andrei Alexandrescu wrote:
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Sooner or later that will need to be defined. I know next to nothing
about locales. (I know I dislike the design C++ uses.)
D uses Utf-8, and that is *good enough*!
This lets my programs understand Finnish, and doesn't
Walter Bright wrote:
Georg Wrede wrote:
We've had Walter make nice features to D that were laborious to
create, only to see nobody use them. It's happened, ask him.
Sure. Often the only way to see if a feature is useful is to actually
implement it and see what happens. Some features have
Georg Wrede wrote:
(You know, a few years ago we had a major conversation here about
whether non-ASCII variable names should be accepted in D. The end result
is, yes. (I just tried it.) Now, how can an international team cowork on
a project where variable names are written so the other folks
Georg Wrede wrote:
The hypothetical Ambitious Programmer might want to use locale. He could
then have the dates and times (and currencies, etc.) follow the country.
Now, that might sound commendable, but in practice it *crumbles*.
He can't possibly know how to deal with languages that are
is a concept too abstract to be able to do something good with
it. Since you could only define it using Algebraic type and a loosely
defined tree of strings, that seems to confirm my view. Call the module
std.locale if you want, but keep in mind that the most important task
at hand is facilitating
Don wrote:
there's no simple solution. (gripe They could at least recognize that
outside the US, everyone uses A4-size paper, not that bizarro
letter/legal stuff /gripe).
Amen!
It is usual that the user needs to write, say, in Swedish or in
Russian, while in a Finnish setting. Or that one
Andrei Alexandrescu, el 1 de marzo a las 19:40 me escribiste:
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Sooner or later that will need to be defined. I know next to nothing about
locales. (I know I dislike the design C++ uses.)
D uses Utf-8, and that is *good enough*!
This lets my
What is language specific about how an array is formatted? I think
you're abusing the locale stuff as some kind of user customization
mechanism for format().
Michel Fortin, el 2 de marzo a las 07:30 me escribiste:
On 2009-03-02 01:04:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Good idea. But before we do so, I was hoping I'd pick the brains of people
who have used locales in other languages and understand the burning
Georg Wrede wrote:
Andrei Alexandrescu wrote:
An excellent string hierarchy without the entire rest of i18n, is
only going to look like a Ferrari with a Trabant engine. Which is
worse than nothing at all.
I don't understand this. What is the rest of i18n?
i18n stands for
Michel Fortin wrote:
On 2009-03-02 08:32:40 -0500, Leandro Lucarella llu...@gmail.com said:
I'm not following this thread carefully and I don't know if this is what
you are implying, but: Please don't you even think in duplicating the
locale stuff, at least on unix there is a very nice
Andrei Alexandrescu wrote:
Georg Wrede wrote:
*** How to print arrays ***
You print arrays in a predictable and expected way.
D array printing is for non-GUI stuff. Hence, you use the C locale,
period.
I think the C locale (or any predefined locale) tells what left bracket
I should
Mon, 02 Mar 2009 09:34:32 +0200, Georg Wrede wrote:
Of course, eventually we will want to do something about this. But
that should be left to the day when real issues are all sorted out in
D. This is a non-urgent, low-priority thing.
Had there been any need for locales, believe me, the
.
Well I was thinking of passing the buck around. Instead of std.locale
defining a hierarchy for formatting numbers and dates, it provides a
means for user code to plant a routine in the locale object that knows
how to format numbers and dates. Of course, with time default localized
routine
Sergey Gromov wrote:
Mon, 02 Mar 2009 09:34:32 +0200, Georg Wrede wrote:
Of course, eventually we will want to do something about this. But
that should be left to the day when real issues are all sorted out in
D. This is a non-urgent, low-priority thing.
Had there been any need for locales,
Mon, 02 Mar 2009 07:02:10 -0800, Andrei Alexandrescu wrote:
Consider some code in phobos that must throw an exception:
throw Exception(File `%s' not found, system error is %s.,
filename, errnomsg);
The localized version will look like this:
auto format = File `%s' not found,
Andrei Alexandrescu wrote:
Georg Wrede wrote:
You see, we're not communicating. I sent this link:
http://www.unicode.org/cldr/
Did you look at it? It is essentially a database of locale information
in a highly structured format. All I want is to define a structure
expressive enough to gobble
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Georg Wrede wrote:
You see, we're not communicating. I sent this link:
http://www.unicode.org/cldr/
Did you look at it? It is essentially a database of locale information
in a highly structured format. All I want is to define a structure
Sergey Gromov wrote:
Mon, 02 Mar 2009 07:02:10 -0800, Andrei Alexandrescu wrote:
Consider some code in phobos that must throw an exception:
throw Exception(File `%s' not found, system error is %s.,
filename, errnomsg);
The localized version will look like this:
auto format = File `%s'
Christopher Wright wrote:
-- All very nice, but no cigar. That's about as smart as letting
people define *unlimited* length variable names!)
I recently dealt with a programming language that specified a limit of
63 characters for identifier names. This wouldn't have been a
significant
Sergey Gromov wrote:
Mon, 02 Mar 2009 09:34:32 +0200, Georg Wrede wrote:
Of course, eventually we will want to do something about this. But
that should be left to the day when real issues are all sorted out in
D. This is a non-urgent, low-priority thing.
Had there been any need for locales,
Sergey Gromov wrote:
To actually solve this problem the default exception handler must be
fixed to convert any UTF-8 into the current OEM code page before
printing. It would also help if default stdin and stdout performed such
a conversion.
No, stdin/stdout *must* perform this conversion.
On Mon, Mar 2, 2009 at 1:52 PM, Georg Wrede georg.wr...@iki.fi wrote:
My take:
* This is still a moving target
* Using this is a major hassle for the programmer
* With D2 itelf a moving target, nobody is going to invest enough time in
this to actually use it for something worthwhile in
Jarrett Billingsley wrote:
functions for
indexing and slicing on character boundaries) before this.
These already exist in std.uni.
Rainer Deyke wrote:
Sergey Gromov wrote:
To actually solve this problem the default exception handler must be
fixed to convert any UTF-8 into the current OEM code page before
printing. It would also help if default stdin and stdout performed such
a conversion.
No, stdin/stdout *must* perform
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Sergey Gromov wrote:
To actually solve this problem the default exception handler must be
fixed to convert any UTF-8 into the current OEM code page before
printing. It would also help if default stdin and stdout performed such
a conversion.
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Sergey Gromov wrote:
To actually solve this problem the default exception handler must be
fixed to convert any UTF-8 into the current OEM code page before
printing. It would also help if default stdin and stdout performed
Mon, 02 Mar 2009 12:53:48 -0800, Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Sergey Gromov wrote:
To actually solve this problem the default exception handler must be
fixed to convert any UTF-8 into the current OEM code page before
printing. It would also help if default stdin and stdout
Andrei Alexandrescu wrote:
If you want to provide a specific date formatter, you plant a delegate
in the locale table. The code in Phobos doing formatting will detect
that and call your delegate passing in the date. You do whatever you
want on your side (format on the spot, use your own class
Christopher Wright wrote:
Andrei Alexandrescu wrote:
If you want to provide a specific date formatter, you plant a delegate
in the locale table. The code in Phobos doing formatting will detect
that and call your delegate passing in the date. You do whatever you
want on your side (format on
Andrei Alexandrescu wrote:
The localized version will look like this:
auto format = File `%s' not found, system error is %s.;
auto localFormat = currentLocale ? currentLocale.peek(format) : null;
if (!localFormat) localFormat = format;
throw Exception(localFormat, filename, errnomsg);
This
On Mon, 02 Mar 2009 06:28:12 -0800, Andrei Alexandrescu wrote:
You're right, we won't engage in the business of maintaining locale
databases. We provide mechanism, not policy.
Ok, for awhile there I thought you were attempting to duplicate the efforts
that the operating systems already do.
On 2009-03-02 14:58:26 -0500, Walter Bright newshou...@digitalmars.com said:
It's a silly thing, but I love the little google widget you can add to
a web page to automatically translate the pages. All the D site pages
have it in the left column.
It's not a silly thing, it's hilarious. Look,
Michel Fortin wrote:
On 2009-03-02 14:58:26 -0500, Walter Bright newshou...@digitalmars.com
said:
It's a silly thing, but I love the little google widget you can add to
a web page to automatically translate the pages. All the D site pages
have it in the left column.
It's not a silly thing,
On Mon, 02 Mar 2009 18:36:09 -0800, Andrei Alexandrescu wrote:
Phobos has supported Posix positional syntax since 2.006.
http://digitalmars.com/d/2.0/phobos/std_stdio.html
Thank you. I was behind the times (again).
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
for instance: you have a base
class to format dates, another for numbers; you can easily create your
own subclass if you want, and there's a way to get the default
formatter instance.
Well I was thinking of passing the buck around. Instead of std.locale
defining a hierarchy for formatting numbers
Andrei Alexandrescu wrote:
In another post you sounded as if there is a connection between this
stuff and printing arrays. I'm not sure I see the connection.
Very simple. If we have a locale table, I am thinking of dedicating a
branch std in it to stuff that's in std. For example, I can use
Sooner or later that will need to be defined. I know next to nothing
about locales. (I know I dislike the design C++ uses.)
I was thinking of a design along the following lines. There are RFCs
dedicated to locale nomenclature:
http://tools.ietf.org/html/rfc4646 for language names
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g. defaultLocale.
By default the reference will be null, implying the C locale should be
in effect. Applications can assign to it as they find fit, and also pass
around multiple locale variables.
I disagree with
Andrei Alexandrescu wrote:
Sooner or later that will need to be defined. I know next to nothing
about locales. (I know I dislike the design C++ uses.)
D uses Utf-8, and that is *good enough*!
This lets my programs understand Finnish, and doesn't give me undue
headaches.
Seriously tending
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they find
fit, and also pass around multiple locale
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Sooner or later that will need to be defined. I know next to nothing
about locales. (I know I dislike the design C++ uses.)
D uses Utf-8, and that is *good enough*!
This lets my programs understand Finnish, and doesn't give me undue
headaches.
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they find
fit, and also pass around multiple locale
Georg Wrede wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they
find fit, and also pass around
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they
find fit, and also pass
Georg Wrede wrote:
What else? Well, it is conceivable that he wants his program to print
dates and times the way it's done over there. He simply writes the
program by hand so it does dates and times like he wants. Even if
there was a locale thing in the language, he wouldn't bother with the
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they
Walter Bright wrote:
I've attempted to use locales, but the reason I'd always wind up doing
it by hand is because the existing libraries to do it are obtuse,
impenetrable, execrable, and pretty much unusable.
So it may be that it's an insoluble problem, or maybe nobody has come up
with the
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Sooner or later that will need to be defined. I know next to nothing
about locales. (I know I dislike the design C++ uses.)
D uses Utf-8, and that is *good enough*!
This lets my programs understand Finnish, and doesn't give me undue
headaches.
Walter Bright wrote:
Andrei Alexandrescu wrote:
Well I was thinking a global reference might be handy for people who
e.g. want to set the locale once and then be done with it.
That's what I was objecting to!
I think only a few apps actually manipulate multiple locales
simultaneously. Most
Joel C. Salomon wrote:
Walter Bright wrote:
I've attempted to use locales, but the reason I'd always wind up doing
it by hand is because the existing libraries to do it are obtuse,
impenetrable, execrable, and pretty much unusable.
So it may be that it's an insoluble problem, or maybe nobody
Andrei Alexandrescu wrote:
Georg Wrede wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
There will be a global reference to a Locale class, e.g.
defaultLocale. By default the reference will be null, implying the C
locale should be in effect. Applications can assign to it as they
find
68 matches
Mail list logo
